Mail Archives: djgpp/1997/06/16/14:57:01
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
- Raw text -