From owner-svn-src-all@FreeBSD.ORG Fri Sep 17 00:21:02 2010 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9873B106564A; Fri, 17 Sep 2010 00:21:02 +0000 (UTC) (envelope-from obrien@NUXI.org) Received: from dragon.nuxi.org (trang.nuxi.org [74.95.12.85]) by mx1.freebsd.org (Postfix) with ESMTP id 700328FC08; Fri, 17 Sep 2010 00:21:02 +0000 (UTC) Received: from dragon.nuxi.org (obrien@localhost [127.0.0.1]) by dragon.nuxi.org (8.14.4/8.14.4) with ESMTP id o8H0L1OZ014002; Thu, 16 Sep 2010 17:21:01 -0700 (PDT) (envelope-from obrien@dragon.nuxi.org) Received: (from obrien@localhost) by dragon.nuxi.org (8.14.4/8.14.4/Submit) id o8H0L1M6014001; Thu, 16 Sep 2010 17:21:01 -0700 (PDT) (envelope-from obrien) Date: Thu, 16 Sep 2010 17:21:01 -0700 From: "David O'Brien" To: Jilles Tjoelker Message-ID: <20100917002101.GA13653@dragon.NUXI.org> References: <201009091927.o89JReXm022426@svn.freebsd.org> <20100909195302.GA48144@stack.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100909195302.GA48144@stack.nl> X-Operating-System: FreeBSD 9.0-CURRENT X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? User-Agent: Mutt/1.5.16 (2007-06-09) Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org Subject: Re: svn commit: r212374 - head/usr.bin/printf X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: obrien@freebsd.org List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Sep 2010 00:21:02 -0000 On Thu, Sep 09, 2010 at 09:53:02PM +0200, Jilles Tjoelker wrote: > On Thu, Sep 09, 2010 at 07:27:40PM +0000, David E. O'Brien wrote: > > +.Pp > > +Trying to print a dash ("-") as the first character causes > > +.Nm > > +to interpet the dash as a program argument. > > +.Nm -- > > +must be used before > > +.Ar format . > > I do not consider this a bug. [..] > A caveat could be added, OK, if not a bug, then can you suggest other language (and position in the man page) to give a warning or hint against something I think goes against POLA? For something that does not claim to have any command line arguments, I would not have expected getopt() to be used and thus need to escape out of its processing. > POSIX requires printf to recognize -- and > pretty much all current implementations conform to this. Please provide a reference. I am looking at 'The Open Group Base Specifications Issue 6 IEEE Std 1003.1, 2004 Edition' (susv3/utilities/printf.html), and I am not seeing such language. susv3 has the synopsis as: SYNOPSIS printf format [argument...] OPERANDS The following operands shall be supported: format A string describing the format to use to write the remaining operands. See the EXTENDED DESCRIPTION section. argument The strings to be written to standard output, under the control of format. See the EXTENDED DESCRIPTION section. 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. #include int main(void) { printf("%d\n", 9999999999); printf("%d\n", -9999999999); return 0; } -- -- David (obrien@FreeBSD.org)