Date: Sun, 6 Jul 2003 19:29:06 +1000 From: Peter Jeremy <peterjeremy@optushome.com.au> To: src-committers@FreeBSD.org, cvs-src@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/lib/libc/stdio vfscanf.c Message-ID: <20030706092906.GA46974@cirb503493.alcatel.com.au> In-Reply-To: <20030706051302.GA22242@HAL9000.homeunix.com> References: <200306280903.h5S936Em045685@repoman.freebsd.org> <20030628090418.GA30292@HAL9000.homeunix.com> <20030702194602.GB21606@cirb503493.alcatel.com.au> <20030706051302.GA22242@HAL9000.homeunix.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Jul 05, 2003 at 10:13:02PM -0700, David Schultz wrote: >On Thu, Jul 03, 2003, Peter Jeremy wrote: >> 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(). Agreed. There's probably some ongoing additional effort in maintaining the three pieces of code but, based on BDE's comments, I'll withdraw my suggestion. >> 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. I doubt it's a real problem for anyone and it's not something that I think is worth spending effort on (other than as part of a 'avoid arbitrary limits' cleanup). The limit would just disappear as a side-effect: fstrtod() wouldn't need the incoming string copied into a local buffer as strtod() does. Peter
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030706092906.GA46974>