From owner-cvs-lib  Tue Jul  1 13:07:26 1997
Return-Path: <owner-cvs-lib>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.5/8.8.5) id NAA17906
          for cvs-lib-outgoing; Tue, 1 Jul 1997 13:07:26 -0700 (PDT)
Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19])
          by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id NAA17900;
          Tue, 1 Jul 1997 13:07:19 -0700 (PDT)
Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.5/8.6.9) id GAA02012; Wed, 2 Jul 1997 06:05:39 +1000
Date: Wed, 2 Jul 1997 06:05:39 +1000
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199707012005.GAA02012@godzilla.zeta.org.au>
To: cvs-all@FreeBSD.ORG, cvs-committers@FreeBSD.ORG, cvs-lib@FreeBSD.ORG,
        jkh@FreeBSD.ORG
Subject: Re: cvs commit: src/lib/libc/stdio scanf.3 vfscanf.c
Sender: owner-cvs-lib@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

>jkh         1997/07/01 10:46:40 PDT
>
>  Modified files:
>    lib/libc/stdio       scanf.3 vfscanf.c 
>  Log:
>  Add 64 bit int support to scanf()
>  PR:		2080
>  Submitted by:	David Dawes <dawes@rf900.physics.usyd.edu.au>

I had this patch in my "needs more work" basket.  Its use of strtoq() and
strtouq() for ints and longs is inefficient in all cases and incompatible
in overflow cases.  The behaviour in overflow cases seems to be undefined,
so it isn't a bug that the submitted patch would change the result read
by sscanf("4294967296", "%ld", &foo) from INT_MAX to 0 (for 32-bit ints),
it is just incompatible.

The int vs long case was already poorly handled by using strtol() and
strtoul() for ints.

Bruce