From owner-cvs-src@FreeBSD.ORG  Fri Jul  4 08:34:13 2003
Return-Path: <owner-cvs-src@FreeBSD.ORG>
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 F1C7437B401; Fri,  4 Jul 2003 08:34:12 -0700 (PDT)
Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16])
	by mx1.FreeBSD.org (Postfix) with ESMTP
	id 1ED9643FDD; Fri,  4 Jul 2003 08:34:11 -0700 (PDT)
	(envelope-from bde@zeta.org.au)
Received: from katana.zip.com.au (katana.zip.com.au [61.8.7.246])
	by mailman.zeta.org.au (8.9.3p2/8.8.7) with ESMTP id BAA23154;
	Sat, 5 Jul 2003 01:34:05 +1000
Date: Sat, 5 Jul 2003 01:34:04 +1000 (EST)
From: Bruce Evans <bde@zeta.org.au>
X-X-Sender: bde@gamplex.bde.org
To: Peter Jeremy <peterjeremy@optushome.com.au>
In-Reply-To: <20030702194602.GB21606@cirb503493.alcatel.com.au>
Message-ID: <20030705012315.E16356@gamplex.bde.org>
References: <200306280903.h5S936Em045685@repoman.freebsd.org>
	<20030702194602.GB21606@cirb503493.alcatel.com.au>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
cc: cvs-src@FreeBSD.org
cc: src-committers@FreeBSD.org
cc: cvs-all@FreeBSD.org
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 <cvs-src.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/cvs-src>,
	<mailto:cvs-src-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/cvs-src>
List-Post: <mailto:cvs-src@freebsd.org>
List-Help: <mailto:cvs-src-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/cvs-src>,
	<mailto:cvs-src-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Fri, 04 Jul 2003 15:34:13 -0000

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