Date: Sat, 5 Jul 2003 22:13:02 -0700 From: David Schultz <das@FreeBSD.ORG> To: Peter Jeremy <peterjeremy@optushome.com.au> Cc: cvs-all@FreeBSD.ORG Subject: Re: cvs commit: src/lib/libc/stdio vfscanf.c Message-ID: <20030706051302.GA22242@HAL9000.homeunix.com> In-Reply-To: <20030702194602.GB21606@cirb503493.alcatel.com.au> References: <200306280903.h5S936Em045685@repoman.freebsd.org> <20030628090418.GA30292@HAL9000.homeunix.com> <20030702194602.GB21606@cirb503493.alcatel.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Jul 03, 2003, Peter Jeremy wrote: > On Sat, Jun 28, 2003 at 02:04:19AM -0700, David Schultz wrote: > >On Sat, Jun 28, 2003, David Schultz wrote: > >> Revamp scanf's floating-point-parsing algorithm to support > >> [+|-]Inf, [+|-]NaN, nan(...), and hexidecimal FP constants. > ... > >The new code should correctly parse any well-formed floating point > >number, but if you notice any problems, set (extern int) scanfdebug > >to 1. This will cause scanf() to dump core if it notices that > >strtod() disagrees with it about how long the number is. > > vfscanf() does numeric conversion by calling strtoX() functions as > appropriate. One side-effect of this is that vfscanf() needs to > replicate the number parsing code in the strtoX() functions to > convert the incoming FILE* stream into a character array as needed > by strtoX() functions. > > It would seem cleaner to use a common underlying set of conversion > functions, similar to strtoX() but taking taking a FILE* and a width > instead of a char*. The strtoX() functions can hand-craft the FILE > structure much as sscanf() does. In principle, you're right, but there are a number of problems. BDE touched on the key technical issues. Another reason not to do as you suggest is that in order to seamlessly integrate the two, someone would have to overhaul the vendor's implementations of strtod() and strtodg(). Even if I wanted to do that, the ensuing political battle would likely take hours of time, whereas the present solution required 15 minutes of coding and 30 minutes of testing and debugging. > This conversion also results in the 512 > character limit on numeric strings. This is an age-old limitation. I considered removing it, but then realized that I have yet to encounter anyone who cares. 512 characters is a BIG floating point number---much larger than the precision supported by readily available hardware.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030706051302.GA22242>