cvs commit: src/lib/libc/stdio vfscanf.c

[David Schultz]

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.