Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT sources DOT redhat DOT com Delivered-To: mailing list cygwin AT sources DOT redhat DOT com Message-ID: <3AE9EE63.5F78FF3@cygnus.com> Date: Fri, 27 Apr 2001 18:10:43 -0400 From: "J. Johnston" Organization: Red Hat Inc. X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-2smp i686) X-Accept-Language: en MIME-Version: 1.0 To: "Charles S. Wilson" CC: Mark Schamberger , cygwin AT cygwin DOT com, newlib AT sources DOT redhat DOT com Subject: Re: bug report: sscanf problem with cygwin 1.3.1-1 References: <3AE9A1EA DOT EC0961C6 AT labs DOT mot DOT com> <3AE9BB2B DOT 555C60D7 AT ece DOT gatech DOT 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 * libc/stdio/vfscanf.c (__svfscanf_r): Initialize new_exp local var. 2001-04-27 Jeff Johnston * 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 > > > > 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 AT labs DOT mot DOT 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