No exception handling in NCEG ??

[Alan M. McKenney]

    I recently had a discussion in the USENET group
"comp.os.linux.development.system" about what passes for
floating-point exception handling in the operating system LINUX
(a Unix clone, mainly for 80x86-based systems.)  Someone told me
that NCEG was discussing IEEE exceptional value handling, but
that none of the proposals has anything to say about floating
point exception traps or trap handling.

    Is this true?

    If so, I am surprised not to see any complaints about it here.
Granted, numeric-interest is not primarily concerned with C
implementations.  However:

1.  This appears to me to be part of a larger tendency to ignore
    floating-point exceptions.  More and more, I read postings from
    people complaining that a code that ran without bombing on
    system A (with traps masked off by default) bombs on system B
    (with traps enabled by default), asking how to disable traps.

    I doubt that these posters have carefully coded their
    entire code to get correct (or reasonable) results even with
    Inf's and NaN's as intermediate results; it seems more likely
    that they have been lulled by the IEEE-specified no-trap
    behavior into not taking divide-by-zero or overflow seriously.

    This *should* be of concern to those who care about whether
    floating-point code produces reasonable or totally bogus
    answers, which I assume includes the readers of this mailing
    list.


2.  The dominant OS for systems larger than PC's is Unix (or some
    variant thereof), and Unix is C-based[*].  If there is going to
    be a standard for Unix, it will be a C-based standard.

    Now, as far as I know, none of the Unix standards addresses
    enabling or handling floating-point traps, so if NCEG doesn't
    either, then we will continue to have the current situation:

    each system has a different, barely documented way to enable
    and handle floating-point exception traps, or (in some cases)
    none at all.

[*] Moreover, even Mac and Microsoft systems tend to be programmed
    with Unix-like libraries.


3.  I remember W. Kahan giving a talk on floating-point exceptions,
    and what you could do with flexible exception handling; this
    sounds like something of interest to this mailing list.

    However, this cannot be done (in present systems) without
    having trap handlers, and ones that are given a fair amount
    of FPU state.

    Instead, the trend seems to be not to give trap handlers any
    information, not even what exception(s) occurred or where
    it/they occurred.