From: Phil Galbiati <galbiati AT cse DOT ogi DOT edu>
Newsgroups: comp.os.msdos.djgpp
Subject: Re: Symify crashes in Windows Dos box
Date: Thu, 12 Jun 1997 01:25:11 -0700
Organization: Oregon Graduate Institute - Computer Science & Engineering
Lines: 65
Message-ID: <Pine.SUN.3.95.970611223731.4946A-100000@blue.cse.ogi.edu>
References: <Pine DOT SUN DOT 3 DOT 91 DOT 970610111843 DOT 3067T-100000 AT is>
Reply-To: Phil Galbiati <galbiati AT cse DOT ogi DOT edu>
NNTP-Posting-Host: blue.cse.ogi.edu
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
In-Reply-To: <Pine.SUN.3.91.970610111843.3067T-100000@is>
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp
Precedence: bulk


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