From owner-freebsd-current@FreeBSD.ORG Tue Apr 12 19:42:46 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D2D4716A4CE for ; Tue, 12 Apr 2005 19:42:46 +0000 (GMT) Received: from cvs.openbsd.org (cvs.openbsd.org [199.185.137.3]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8C58843D5E for ; Tue, 12 Apr 2005 19:42:46 +0000 (GMT) (envelope-from deraadt@cvs.openbsd.org) Received: from cvs.openbsd.org (localhost [127.0.0.1]) by cvs.openbsd.org (8.13.3/8.12.1) with ESMTP id j3CJj3Fr006856; Tue, 12 Apr 2005 13:45:03 -0600 (MDT) Message-Id: <200504121945.j3CJj3Fr006856@cvs.openbsd.org> To: Thorsten Glaser In-reply-to: Your message of "Tue, 12 Apr 2005 19:35:03 -0000." Date: Tue, 12 Apr 2005 13:45:03 -0600 From: Theo de Raadt X-Mailman-Approved-At: Wed, 13 Apr 2005 15:55:49 +0000 cc: miros-discuss@mirbsd.org cc: freebsd-current@freebsd.org cc: tech@openbsd.org Subject: Re: strtonum(3) in FreeBSD? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2005 19:42:46 -0000 > >> Quick, sort of, question. Is it worth it to bring strtonum(3) from > >> OpenBSD into FreeBSD-CURRENT. I have the diffs if that's the case, I > >> know that the newer packet filter code from OPENBSD_3_7 that mlaier@ and > >> I are working on uses it in a few places (see: pflogd) but I'm not sure > >> of the merits of bringing strtonum(3) into lib/libc/stdlib... > >> > >> In theory, it should be a better implementation of what atoi(3) and > >> strtol(3) do, but as tg@(mirbsd.org) pointed out to the OpenBSD fellows > >> and myself, it doesn't take hexadecimal values well... > >> > >> Somebody let me know, i've got diffs ready, sort of ;) > >> (or let me know why it's a bad idea) > > > >The lack of base handling argument does make it less appealing, but now > >that OpenBSD has used this name, we're stuck with the API. I would > > Accepting "0x10" as 16 instead of 0 is no API breakage, > it only changes the behaviour. To the good, I might add. > > I'd suggest to not add octal (010) parsing, because > leading zeroes are not totally uncommon in the > purely-decimal world. > > >request that you use intmax_t rather than "long long" for the integers. > >Then the API scales cleanly when some future processor adds 128-bit ints. > >Since intmax_t is "long long" on all current platforms that wouldn't > >cause compatability problems with OpenBSD. > > I second that. Cc'd to OpenBSD-Tech. Comments? We are not changing it. This API was very carefully chosen so that it is EASY TO USE. People can easily change existing code and use this API to write better code. That is the #1 design decision. If you must deal with octal and hex numbers, do it yourself. This is not the typical case, and we specially avoid handling them to keep this simple.