Re: Incorrect option processing in builtin printf(1)

[Eric Blake]

On 7/22/19 12:56 PM, kre@munnari.OZ.AU wrote:
> Configuration Information [Automatically generated, do not change]:
> Machine: x86_64
> OS: netbsd
> Compiler: gcc
> Compilation CFLAGS: -O2 -D_FORTIFY_SOURCE=2 -I/usr/include -Wno-parentheses 
> -Wno-format-security
> uname output: NetBSD jinx.noi.kre.to 8.99.30 NetBSD 8.99.30 (1.1-20190114) 
> #9: Mon Jan 14 13:29:08 ICT 2019  
> kre@onyx.coe.psu.ac.th:/usr/obj/testing/kernels/amd64/JINX amd64
> Machine Type: x86_64--netbsd
> 
> Bash Version: 5.0
> Patch Level: 7
> Release Status: release
> 
> Description:
>       POSIX specifies that printf(1) has no options, and by not

Correct that there are no POSIX-mandated options,...

>       specifying that it is intended to comply with XBD 12.2 effectivly
>       says that it is not.   That is, in printf, the first arg is
>       always the format string, whatever it contains.

...but wrong that it is not allowed to have options as extensions.  XBD
12.2 states "Some of the standard utilities do not conform to all of
these guidelines; in those cases, the OPTIONS sections describe the
deviations." and "The utilities in the Shell and Utilities volume of
POSIX.1-2017 that claim conformance to these guidelines shall conform
completely to these guidelines as if these guidelines contained the term
"shall" instead of "should"."

Then further in XSH, POSIX states in XSH 1.4
(https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap01.html)
that "Default Behavior: When this section is listed as "None.", it means
that the implementation need not support any options. Standard utilities
that do not accept options, but that do accept operands, shall recognize
"--" as a first argument to be discarded." and again for 'printf'
(https://pubs.opengroup.org/onlinepubs/9699919799/utilities/printf.html)
"OPTIONS
    None."

You are correct that for some utilities, POSIX does not require
compliance with the Utility Syntax Guidelines (XSH 2.14 states that the
special shell builtins do not comply by default without explicit
mention, which is the opposite of other utilities that DO comply by
default without explicit mention).  But since printf is not one of the
special builtins, and does not document an exemption, it must comply
with the relevant Utility Syntax Guidelines.

> 
>       So
>               printf ---              should print three - chars to stdout

Not so.  The utility syntax guidelines state that you have invoked
unspecified behavior, because you started an argument with '-' but which
is not intended to be parsed as an option. The implementation may treat
it as a literal string, but may equally treat it as an attempt to parse
it as the first '-' requesting an option, the second '-' being the
option character being requested, but treating it as an error since no
option named '-' exists.  If you want to output a literal string
containing three dashes, you MUST write 'printf -- ---'.

>               printf -%d 3            should print -3 to stdout

Not so. POSIX doesn't require extension options, but also does not
forbid them. Bash happens to have extension options, so your command
line is not portable, and it is not a bug in bash.


>       Please, let's try to avoid losing control of printf like what
>       happened to echo, stick to the requirements of POSIX where they
>       apply and actually speficy the output required.

POSIX already specifies the bash behavior as permitted. There is nothing
to change here but your broken command lines.

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3226
Virtualization:  qemu.org | libvirt.org

signature.asc
Description: OpenPGP digital signature