Mailing-List: contact cygwin-help@sourceware.cygnus.com; run by ezmlm
Sender: cygwin-owner@sources.redhat.com
Message-ID: <3AE9EE63.5F78FF3@cygnus.com>
Date: Fri, 27 Apr 2001 18:10:43 -0400
From: "J. Johnston" <jjohnstn@cygnus.com>
Organization: Red Hat Inc.
MIME-Version: 1.0
To: "Charles S. Wilson" <cwilson@ece.gatech.edu>
CC: Mark Schamberger <Mark_Schamberger-A11451@email.mot.com>,
        cygwin@cygwin.com, newlib@sources.redhat.com
Subject: Re: bug report:  sscanf problem with cygwin 1.3.1-1
References: <3AE9A1EA.EC0961C6@labs.mot.com> <3AE9BB2B.555C60D7@ece.gatech.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

"Charles S. Wilson" wrote:
> 
> Confirmed. I used vsscanf() as my test case, but all *scanf() functions
> in newlib call the same workhorse function, __svfscanf_r().
> 
> It looks like there is a problem handling decimal points in __svfscanf_r
> (newlib/libc/stdio/vfscanf.c line 227) but I can't find it by inspection
> and I don't have a debuggable cygwin1.dll handy.  There have been a few
> changes in that code lately, but look at the recent diffs doesn't show
> any reason why decimal point handling would stop working.
> 
> Can somebody with a debuggable version of newlib/cygwin1 try to track
> this down -- Mark's sample code should generate a nice simple test case
> with which to gdb the newlib code.  Meanwhile, I'll start a debuggable
> kernel build...
> 

I have tried a few other platforms as I am having strange problems with my Cygwin build.

First of all, I found a problem whereby the _strtod_r prototype was missing which caused the mn10300
build to fail the test case.  I have checked in a patch for this and it works fine.  The mn10300
differs from Cygwin in that it doesn't set the WANT_IO_LONG_DBL flag on when building.  Thus, it
uses strtod rather than strtold as its workhorse.

I also noticed that there was a warning about a local variable that may not be initialized so I have
also checked in a patch for that just in case.

With that last patch I built a static i686 linux build and set the WANT_IO_LONG_DBL flag to true
when building vfprintf.o and vfscanf.o.  The test case runs successfully and I am also able to run
Stephen Moshier's ieeetst with no errors.

The ChangeLogs for the two patchs are:

2001-04-27  Jeff Johnston  <jjohnstn@redhat.com>

        * libc/stdio/vfscanf.c (__svfscanf_r): Initialize new_exp local var.

2001-04-27  Jeff Johnston  <jjohnstn@redhat.com>

        * libc/include/stdlib.h: Add prototype for _strtod_r.

If I am able, I will look into it further on the weekend.

-- Jeff J.

> Mark Schamberger wrote:
> >
> > I have verified this problem on three different machines, each with the
> > complete "current" installation of cygwin.  (Windows NT4.0 sp6, Windows
> > 2000 sp1)
> >
> > When using sscanf to read double values from a string, the resulting
> > value is incorrect.  The following piece of code demonstrates the
> > problem:
> >
> > >>>>>>>>>>>>>>>>>>>>>
> > #include <stdio.h>
> >
> > int main(int argc, char *argv[])
> > {
> >         double d;
> >
> >         sscanf("12.345","%lg",&d);
> >         printf("%lg\n",d);
> > }
> > >>>>>>>>>>>>>>>>>>>>>
> >
> > Instead of the expected 12.345, it results in 12345 (it appears that
> > decimal points and exponents are not understood properly).
> >
> > If I revert FROM cygwin 1.3.1-1 back TO cygwin 1.1.8-2, the bug
> > disappears.
> >
> > Anyone else experience this problem?
> >
> > Thanks, Mark Schamberger
> > mas@labs.mot.com
> >
> > --
> > Want to unsubscribe from this list?
> > Check out: http://cygwin.com/ml/#unsubscribe-simple

--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple