RFC: Fix partial NaN-parsing problem [was RE: sscanf problem]

Dave Korn dave.korn@artimi.com
Mon Apr 4 18:35:00 GMT 2005

----Original Message----
>From: Dave Korn
>Sent: 04 April 2005 19:07

> ----Original Message----
>> From: Dave Korn
>> Sent: 04 April 2005 18:51
>> ----Original Message----
>>> From: Michael Hines
>>> Sent: 04 April 2005 19:43
>>> The following program prints
>>> i=1 x=0
>>> instead of
>>> i=0 x=10
>>> when using the latest version of cygwin1.dll.

>   No, hang on, on checking the newlib-l archive that seems to have been
> something to do with a zero exponent.  This is a separate bug: it accepts
> the first one or two characters of 'nan' and says "ok, everything's still
> good", and then because it's reached the end of the string it treats that
> as a successful parse; it forgets to verify that it doesn't have an
> outstanding half-formed NaN.  I'll post a (provisional) patch shortly.

  Ok, this is only provisional, because as I point out I'm not quite sure
about the corner case where we've refilled the buffer.  It also has minor
formatting issues (slightly long lines in the comment, IMO).  However, it
fixes the testcase, and I've got to go home for the evening, so here's my
work-in-progress; comments welcomed.

dk@mace /test/sscanf> cat ss.c

#include <stdio.h>
int main() {
         int i;
         double x;
         x = 10;
         i = sscanf("n", "%lf", &x);
         printf("i=%d x=%g\n", i, x);
         i = sscanf("nan", "%lf", &x);
         printf("i=%d x=%g\n", i, x);
         return 0;

dk@mace /test/sscanf> gcc -O0 -g ss.c -o ss.exe
dk@mace /test/sscanf> ./ss.exe
i=0 x=10
i=1 x=NaN
dk@mace /test/sscanf>

Can't think of a witty .sigline today....
-------------- next part --------------
A non-text attachment was scrubbed...
Name: newlib-sscanf-nan-bug-patch.diff
Type: application/octet-stream
Size: 1422 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/newlib/attachments/20050404/5a03457c/attachment.obj>

More information about the Newlib mailing list