Date: Thu, 16 Sep 2010 17:21:01 -0700 From: "David O'Brien" <obrien@freebsd.org> To: Jilles Tjoelker <jilles@stack.nl> Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org Subject: Re: svn commit: r212374 - head/usr.bin/printf Message-ID: <20100917002101.GA13653@dragon.NUXI.org> In-Reply-To: <20100909195302.GA48144@stack.nl> References: <201009091927.o89JReXm022426@svn.freebsd.org> <20100909195302.GA48144@stack.nl>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <stdio.h>
int
main(void)
{
printf("%d\n", 9999999999);
printf("%d\n", -9999999999);
return 0;
}
--
-- David (obrien@FreeBSD.org)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20100917002101.GA13653>