From owner-svn-src-head@FreeBSD.ORG Fri Sep 17 11:43:39 2010 Return-Path: Delivered-To: svn-src-head@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0230C106566C; Fri, 17 Sep 2010 11:43:39 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail01.syd.optusnet.com.au (mail01.syd.optusnet.com.au [211.29.132.182]) by mx1.freebsd.org (Postfix) with ESMTP id 8C1928FC1A; Fri, 17 Sep 2010 11:43:38 +0000 (UTC) Received: from c122-107-116-249.carlnfd1.nsw.optusnet.com.au (c122-107-116-249.carlnfd1.nsw.optusnet.com.au [122.107.116.249]) by mail01.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id o8HBhYlE018483 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 17 Sep 2010 21:43:35 +1000 Date: Fri, 17 Sep 2010 21:43:34 +1000 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: "David O'Brien" In-Reply-To: <20100917002101.GA13653@dragon.NUXI.org> Message-ID: <20100917212708.Y771@delplex.bde.org> References: <201009091927.o89JReXm022426@svn.freebsd.org> <20100909195302.GA48144@stack.nl> <20100917002101.GA13653@dragon.NUXI.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: svn-src-head@FreeBSD.org, svn-src-all@FreeBSD.org, src-committers@FreeBSD.org, Jilles Tjoelker Subject: Re: svn commit: r212374 - head/usr.bin/printf X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Sep 2010 11:43:39 -0000 On Thu, 16 Sep 2010, David O'Brien wrote: > ... > Interestingly, we may not be compliant with susv3 if I am reading this > correctly: > > The printf utility is required to notify the user when conversion > errors are detected while producing numeric output; thus, the > following results would be expected on an implementation with 32-bit > twos-complement integers when %d is specified as the format operand: > > Argument Standard Output Diagnostic Output > 5a 5 printf: "5a" not completely converted > 9999999999 2147483647 printf: "9999999999" arithmetic overflow > -9999999999 -2147483648 printf: "-9999999999" arithmetic overflow > ABC 0 printf: "ABC" expected numeric value > > > $ uname -m > i386 > $ for A in 5a 9999999999 -9999999999 ABC do /usr/bin/printf "%d\n" $A ; done > printf: 5a: not completely converted > 5 > 9999999999 > -9999999999 > printf: ABC: expected numeric value > 0 > > Though this is in the "informative" section, so maybe this is just one > set of compliant output. Though It is my read that printf(1) should > behave like printf(3), which the above does not for these long long int > values. The implementation actually uses [u]quad_t integers (blech -- it should use [u]intmax_t integers). This may be conformant. POSIX has the general bug of making low-quality implementations, that only support plain integers for command-line options, conformant, and may even require not supporting larger integers in some cases, but hopefully it doesn't require this bug for printf(1). > #include > int > main(void) > { > printf("%d\n", 9999999999); > printf("%d\n", -9999999999); > return 0; > } Restricting to plain int for printf(1) would be less than useful, since unlike printf(3), it has no way of controlling the integer size -- even "%ld" format is "illegal" (should be "invalid") for printf(1). Users wanting to handle large integers would have to use floating point with "%.0f" format, which has some advantages anyway, but printf(1)'s FP format is only double precision, so it doesn't work right for integers >= 2**53 even on arches that have working long double precision. Rounding errors are also not reported for integers >= 2**53 when represented as doubles: $ printf %.0f\\n 9999999999999999 10000000000000000 and its documentation is slightly wrong in saying (re-quoting the above): > The printf utility is required to notify the user when conversion > errors are detected while producing numeric output; thus ... since in the floating point case, it is very unusual for there not to be a rounding error (e.g., 0.1 is not exactly representable in base 2 FP), so reporting _all_ rounding errors would be wrong. In fact, it doesn't seem to be done at all for rounding errors. Bruce