From owner-cvs-src@FreeBSD.ORG Sun Jul 6 02:29:24 2003 Return-Path: Delivered-To: cvs-src@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 52FBE37B401; Sun, 6 Jul 2003 02:29:23 -0700 (PDT) Received: from cirb503493.alcatel.com.au (c20257.belrs2.nsw.optusnet.com.au [198.142.180.81]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0C36044025; Sun, 6 Jul 2003 02:29:15 -0700 (PDT) (envelope-from peterjeremy@optushome.com.au) Received: from cirb503493.alcatel.com.au (localhost.alcatel.com.au [127.0.0.1])h669T7Qv046995; Sun, 6 Jul 2003 19:29:07 +1000 (EST) (envelope-from jeremyp@cirb503493.alcatel.com.au) Received: (from jeremyp@localhost) by cirb503493.alcatel.com.au (8.12.8/8.12.8/Submit) id h669T6DZ046994; Sun, 6 Jul 2003 19:29:06 +1000 (EST) Date: Sun, 6 Jul 2003 19:29:06 +1000 From: Peter Jeremy To: src-committers@FreeBSD.org, cvs-src@FreeBSD.org, cvs-all@FreeBSD.org Message-ID: <20030706092906.GA46974@cirb503493.alcatel.com.au> References: <200306280903.h5S936Em045685@repoman.freebsd.org> <20030628090418.GA30292@HAL9000.homeunix.com> <20030702194602.GB21606@cirb503493.alcatel.com.au> <20030706051302.GA22242@HAL9000.homeunix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030706051302.GA22242@HAL9000.homeunix.com> User-Agent: Mutt/1.4.1i Subject: Re: cvs commit: src/lib/libc/stdio vfscanf.c X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Jul 2003 09:29:25 -0000 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