From owner-freebsd-current@FreeBSD.ORG Tue Apr 12 19:35:18 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 751EA16A4CE for ; Tue, 12 Apr 2005 19:35:18 +0000 (GMT) Received: from thor.66h.42h.de (mirsolutions.de [81.169.132.156]) by mx1.FreeBSD.org (Postfix) with ESMTP id 96A7943D4C for ; Tue, 12 Apr 2005 19:35:16 +0000 (GMT) (envelope-from tg@66h.42h.de) Received: from odem.66h.42h.de (root@odem.66h.42h.de [IPv6:2001:6f8:94d:1:2c0:9fff:fe1a:6a01]) by thor.66h.42h.de (8.13.1/8.13.1) with ESMTP id j3CJZBQS006776 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 12 Apr 2005 19:35:13 GMT Received: from localhost (tg@localhost [IPv6:::1]) by odem.66h.42h.de (8.13.3/8.13.3) with ESMTP id j3CJZ3LU013866 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 12 Apr 2005 19:35:05 GMT Date: Tue, 12 Apr 2005 19:35:03 +0000 (UTC) From: Thorsten Glaser To: freebsd-current@freebsd.org, miros-discuss@mirbsd.org, tech@openbsd.org In-Reply-To: <1113334228.27362.35.camel@localhost.localdomain> Message-ID: References: <1113334228.27362.35.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailman-Approved-At: Wed, 13 Apr 2005 15:55:49 +0000 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:35:18 -0000 Dixitur: >> 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? //mirabile