(The following definitely pertains to port-i386.  I am running 1.5,
proper.  I have no means to test it on other ports.  I assume that this is
generic to all ports, however, and so I'm posting to this list rather than
to port-i386.)


According to K&R2, SIGFPE should occur on ``e.g., zero divide or
overflow''.  According to signal(7), this is a ``floating-point
exception''; this is reasonable to expect, since it _is_ SIGFPE.

However, when I register a SIGFPE handler, and then divide a float or
double by 0, or overflow a float or double, it does not raise the handler.

On the other hand, it DOES raise(SIGFPE) if I divide an integer by
0.  (But not if I overflow the integer by normal arith. operations.)


So, I am bothered by:

 (a) No detection for overflow.

 (b) Inasmuch as SIGFPE seems to be used, it is applied to integer
     arithmetic, rather than to floating point arithmetic.

One can argue that since K&R2 doesn't mention floating point arithmetic,
and only suggests overflow as an example, SIGFPE is behaving as K&R2
predict.  But, certainly, it is in disagreement with our man-page,
signal(7).

Peeking around in our libm sources, it looks like some routines (e.g.,
e_acos.c) expect that dividing a floating point type by 0 will raise a
signal.


I queried the NetBSD bug database, which turned up 1833.  It is the only
SIGFPE report that I could find...and I'm bothered by what it is saying.  
It objected that the i386 INTO _integer_ overflow instruction was failing
to riase SIGFPE.  That was in 1995; it was closed in 1998 as being
long-since fixed.

I'm not sure if this is a documentation flaw, or a bug with our libm (or
perhaps something else---kernel?).  And, I'm not 100% sure what we should
really expect SIGFPE to do.  But we definitely have conflicts.

I'll be happy to send-pr if someone can say definitively whether it's a
doc, library, or kernel bug (or some combination thereof).


  "I probably don't know what I'm talking about." --rauch@eecs.ukans.edu