Re: netbsd build update

[Ben Pfaff]

John Darrington <address@hidden> writes:

> On Thu, May 18, 2006 at 08:27:24PM -0700, Ben Pfaff wrote:
>      John Darrington <address@hidden> writes:
>      
>      > On Thu, May 18, 2006 at 05:25:04PM -0700, Ben Pfaff wrote:
>      >      
>      >      Yes.  I want to call fpsetmask(0) in fp_init().  (The numerous
>      >      manpages that Google returns for fpsetmask() seem to indicate
>      >      that this is the syntax to turn off all exceptions, and they all
>      >      indicate that <ieeefp.h> is the right header to include.)
>      >
>      > I'm not sure that it might not be a better idea to catch SIGFPE and
>      > issue a warning message, and then continue.
>      
>      Why?
>
> Not all floating point errors will result in NaN.  Particularly
> underflow/ overflow errors.  Typically they just result in an
> unchanged variable.  The user will have no idea that his results might
> have bad values.

Underflow goes to 0.  Overflow goes to infinity.  Both of these
are reasonable.

>      Furthermore, I doubt it's possible portably.  I suspect that some
>      CPUs will in fact retry the instruction and fault again in a loop.
>
> They all will.  A signal handler returns to the address that caused it.
> Provided that sigaction (part of the POSIX standard) is supported we
> can reliably overcome this problem thus:
>
> We have two signal handlers:  fpe_handler_ignore, which does nothing,
> and fpe_handler_warn which a) logs a warning message, b) resets the
> handler to fpe_handler_ignore, and c) returns.
>
> At the start of every procedure, the active handler is reset to 
> fpe_handler_warn.   Thus, when a FPE occurs, the user gets a warning,
> the handler is set to ignore further FPEs and the procedure completes
> normally.  The user gets his results, but has been warned that they
> might not be correct.

This sounds like an unreliable mess to me.
-- 
Ben Pfaff 
email: address@hidden
web: http://benpfaff.org