Date: Sat, 5 Jul 2003 01:34:04 +1000 (EST) From: Bruce Evans <bde@zeta.org.au> To: Peter Jeremy <peterjeremy@optushome.com.au> Cc: cvs-all@FreeBSD.org Subject: Re: cvs commit: src/lib/libc/stdio vfscanf.c Message-ID: <20030705012315.E16356@gamplex.bde.org> In-Reply-To: <20030702194602.GB21606@cirb503493.alcatel.com.au> References: <200306280903.h5S936Em045685@repoman.freebsd.org> <20030702194602.GB21606@cirb503493.alcatel.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 3 Jul 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. > ... > 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. > > Benefits: > - Removal of functionally duplicated code (vfscanf.c:parsefloat() > and CT_INT code in vfscanf()) > - Removal of arbitrary(?) 512 char numeric conversion limit > > Disadvantages: > - Additional effort to develop/maintain new code > - Some additional overhead in the strtoX() functions to build the FILE > structure. The scanf family of functions should never be used (*), and I wouldn't like to see the strtoX family of functions pessimized to support unusable functions. (*) Since among other problems, error handling using scanf is impossible. The behaviour of scanf is undefined if the result of a conversion canout be represented. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030705012315.E16356>