svn commit: r212374 - head/usr.bin/printf

[David O'Brien]

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 at FreeBSD.org)