From owner-cvs-lib Tue Jul 1 14:17:33 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id OAA21667 for cvs-lib-outgoing; Tue, 1 Jul 1997 14:17:33 -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 OAA21650; Tue, 1 Jul 1997 14:17:28 -0700 (PDT) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.5/8.6.9) id HAA03617; Wed, 2 Jul 1997 07:13:55 +1000 Date: Wed, 2 Jul 1997 07:13:55 +1000 From: Bruce Evans Message-Id: <199707012113.HAA03617@godzilla.zeta.org.au> To: bde@zeta.org.au, jkh@time.cdrom.com Subject: Re: cvs commit: src/lib/libc/stdio scanf.3 vfscanf.c Cc: cvs-all@FreeBSD.ORG, cvs-committers@FreeBSD.ORG, cvs-lib@FreeBSD.ORG, jkh@FreeBSD.ORG Sender: owner-cvs-lib@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >> I had this patch in my "needs more work" basket. Its use of strtoq() and > >Well, maybe now that it's in the tree and open to wider scrutiny, >somebody can actually push David D. in the direction of greater >"undefined compatibility" :-) Of course, scanf() is as unsafe as gets() and should never be used. Even for ints, you can't rely on the value returned or tell whether there was an overflow. strtoq() seems to be (only) about 3 times slower than strtol(). Bruce --- #include #include #include int main(void) { int i; volatile long l; volatile long long ll; sscanf("4294967296", "%d", &i); printf("this should be %d: %d\n", INT_MAX, i); printf("testing 10^6 strtol()'s of a small value \"123\"\n"); for (i = 0; i < 1000000; ++i) l = strtol("123", 0, 10); printf("testing 10^6 strtoq()'s of a small value \"4294967296\"\n"); for (i = 0; i < 1000000; ++i) l = strtol("4294967296", 0, 10); printf("testing 10^6 strtoq()'s of a small value \"123\"\n"); for (i = 0; i < 1000000; ++i) ll = strtoq("123", 0, 10); printf("testing 10^6 strtoq()'s of a small value \"4294967296\"\n"); for (i = 0; i < 1000000; ++i) ll = strtoq("4294967296", 0, 10); return 0; } ---