Mail Archives: djgpp/1997/06/12/15:07:12
On Tue, 10 Jun 1997, Eli Zaretskii wrote:
>
> On Mon, 9 Jun 1997, Nate Eldredge wrote:
>
> > I might have expected a crash from when symify tries to look at video memory
> > (or however it works), but not a SIGFPE! Anybody know anything about
> > this/have time to debug it?
>
> IMHO, there's nothing to debug here. The original program crashes
> with SIGFPE because it tries to use garbage as an FP number. Nothing
> new here.
Every possible bit-pattern for a floating point number is well-defined
under IEEE-754, so he didn't use "garbage", he used not-a-number.
Just out of curiousity, I ran the program on as many different machines
as I could easily get my hands on, with the following results:
Sun SPARCcenter 2000 - Solaris 2.5.1
-NaN
Sun 4/15 - SunOS 4.1.3_U1 Version B
-NaN
HP 9000/755 - HP-UX 09.03
-?.000000
NeXTstation Turbo - NeXTStep 3.3 [gcc not available, native cc used]
NaN
486DX-33 - Redhat Linux 2.0
NaN
486DX-33 - Windows95 Dos Box [Borland C version 3.1 used]
-NaN
In every case, some indication of NaN (not-a-number) was printed to
stdout, and the program exited gracefully (this is also the DJGPP behavior
when _control87() is called as somebody else suggested). Given DJ's
original intent of providing a tool for porting Unix software to DOS, if
DJGPP's default behavior of crashing is "not a bug", then it is, at best,
a bad design decision which should be changed.
Interestingly enough, without calling _control87(), printf() correctly
handles both positive & negative infinity (0x78000000 and 0xff000000
respectively) by printing "Inf" and "-Inf". Closer inspection of the
return code from _control87() shows the default FPU control register
setting to be 0x37E (-Inf < +Inf, round-to-nearest, extended precision,
and all exceptions handled internally *except* "invalid operation" which
generates a fault). This says the machine is doing what it "should";
however, I question whether what it "should" do is a reasonable choice.
> `symify' crashes because Windows doesn't reset the FPU
> after the first program crashes; nothing new here either.
The repeated SIGFPE which Nate observed, is inconsistent. On my Win95
machine, it does not repeat, but under win3.1 it repeats only on the
command immediately following the initial SIGFPE (i.e. running the
original program generates SIGFPE; running ls generates another SIGFPE;
running ls again works fine).
--Phil Galbiati
- Raw text -