Date: Tue, 15 Jun 1999 09:58:10 +0300 (IDT)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender: eliz AT is
To: Justin Deltener <deltener AT mindtremors DOT com>
cc: djgpp AT delorie DOT com
Subject: Re: FPE
In-Reply-To: <37656D11.9A43A6C@mindtremors.com>
Message-ID: <Pine.SUN.3.91.990615095752.2646K-100000@is>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Reply-To: djgpp AT delorie DOT com
X-Mailing-List: djgpp AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk


On Mon, 14 Jun 1999, Justin Deltener wrote:

> I always thought if I get a Floating Point Exception it was because I
> was dividing by 0!? My program is getting weird FPE's so I made a test
> program to divide a float by 0, and divide 0.0 by a float. Both gave
> answers WITHOUT generating an FPE, soooooo, that kinda shoots that
> theory out the window...

Floating point exception that is caused by division by zero is masked
in DJGPP.  A masked exception prevents SIGFPE from being delivered to
your program, and instead causes the FPU to return an Infinity as the
result.  (Try printing the result of division by zero, and you will
see "Inf" instead of a number.)

In DJGPP v2.01, the only FP exception that was not masked was the
Invalid Operation exception.  Computing a square root of a negative
number is one example where such an exception happens.

However, in v2.02 even the Invalid Operation exception is masked at
startup.  The reason for this is that ANSI C Standard explicitly rules
that programs should not crash if some math library function hits an
abnormal result.

So in v2.02, you should never see a SIGFPE, unless you did something
*really* weird, like pass a char buffer to a function that expects a
double (and even then it is tricky to create an exception).  Instead,
you should see results that print as "Inf" or "NaN".  This assumes
that you haven't changed the FPU exception mask with a call to library
function `_control87', or some equivalent assembly code.  For more
details about this, look up `_control87' in the library reference.

Now back to your FPEs: the right way to debug these problems is to
start with the crash dump printed when the program dies.  The DJGPP
FAQ list explains in section 12.2 how to read the information included
in the crash message, and section 9.2 of the FAQ explains how to make
sense out of the function call traceback printed as part of the crash
message.  This should give you a good idea what happens and where, and
poking with a debugger around that place should pinpoint the bug.