From owner-freebsd-current@FreeBSD.ORG Tue Apr 12 20:49:49 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 77E3816A4CE for ; Tue, 12 Apr 2005 20:49:49 +0000 (GMT) Received: from thor.66h.42h.de (mirsolutions.de [81.169.132.156]) by mx1.FreeBSD.org (Postfix) with ESMTP id 157A043D1F for ; Tue, 12 Apr 2005 20:49:48 +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 j3CKng1n026665 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 12 Apr 2005 20:49:45 GMT Received: from localhost (tg@localhost [IPv6:::1]) by odem.66h.42h.de (8.13.3/8.13.3) with ESMTP id j3CKneA1018980 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 12 Apr 2005 20:49:41 GMT Date: Tue, 12 Apr 2005 20:49:39 +0000 (UTC) From: Thorsten Glaser In-Reply-To: <200504121945.j3CJj3Fr006856@cvs.openbsd.org> Message-ID: References: <200504121945.j3CJj3Fr006856@cvs.openbsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 20:49:49 -0000 Theo de Raadt dixit: >> >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? >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. You already said that, but what about using intmax_t as return type? //mirabile