Date: Mon, 16 Jun 1997 11:52:21 -0700 (PDT)
From: Phil Galbiati <galbiati AT cse DOT ogi DOT edu>
Reply-To: Phil Galbiati <galbiati AT cse DOT ogi DOT edu>
To: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>, dj AT delorie DOT com
cc: djgpp AT delorie DOT com
Subject: Re: Symify crashes in Windows Dos box
In-Reply-To: <Pine.SUN.3.91.970615115607.14561H-100000@is>
Message-ID: <Pine.SUN.3.95.970616013955.15752A-100000@blue.cse.ogi.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Precedence: bulk


On Sun, 15 Jun 1997, Eli Zaretskii wrote:
>
> On Thu, 12 Jun 1997, Phil Galbiati wrote:
> 
> > 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. 
> 
> IMHO, these fine FP-related points in DJGPP are in bad need of
> volunteers.  People who feel they understand these issues are welcome
> to submit source-level patches to library functions that will make it
> be more compliant.

In digging deeper into this, it seems my original diagnosis may not be
correct (or rather, it may not be complete).  Using the tracedump from the 
NaN-printing program, I discovered that the SIGFPE is being generated in
_doprnt() which is called by printf(), and lives in the
$DJDIR\src\libc\ansi\stdio\doprnt.c file.  The guilty statement is the
comparison on line 244:
      if (_ldouble < 0)

_ldouble is the variable which holds the floating point number being
printed, and it doesn't get checked for NaN-ness until cvtl() is called on
line 257, which in turn calls isspeciall() to do the test.

The problem is (assuming my wild-ass assumptions about ANSI printf() are
correct) that if a NaN is passed to printf, with the FPU's control
registers set up for invalid operations to generate SIGFPE's (the default
configuration), this comparison is performed regardless of the contents of
_ldouble.

I have neither a copy of IEEE-754, nor a reliable secondary source which
discusses the standard in sufficient detail for me to discern the
appropriate outcome of a relative comparison to NaN, but it seems
*reasonable* to me for an exception to be raised under these
circumstances.

I am also lacking a copy of the ANSI C standard (don't even know the
number), so I don't know for certain whether printf() is required to not
raise an exception when asked to print a NaN; however, it does NOT seem
reasonable to me that it should be allowed to (in other words, I think it
ought to print "NaN" or something, but that's just one of my wild-ass
assumptions).

If somebody who has access to these standards could comment on the
subject, I would appreciate it.  Once I am convinced that relative
comparisons to NaN should SIGFPE, and that printf() should not, I will
conjure up and post a source-level patch for _doprnt().

Procedural questions for DJ:

1) I seem to recall reading that DJGPP uses its own implementation of
   libc, of which you own the intellectual property rights.  Am I correct
   in assuming that when fixing bugs in it, we must *NOT* under any
   circumstances consult the source code for other implementations,
   including Linux & BSD?

2) I also saw someplace that modifications to the DJGPP source must be
   submitted as patches.  Is this true of total massive overhauls (e.g.,
   if I were to rewrite doprnt.c [800+ lines of hacker byproduct] would
   you still want it as a patch, or would you want my source file)?

3) Is there a design review procedure for bug-fixes & overhauls, or do we
   just submit them when complete, and they get incorporated as is?

--Phil Galbiati