Re: CVS commit: src/usr.bin/printf

[Tobias Nygren <tnn%NetBSD.org@localhost>]

On Tue, 23 Jul 2019 00:31:32 +0700
Robert Elz <kre%munnari.OZ.AU@localhost> wrote:

>     Date:        Mon, 22 Jul 2019 12:23:35 +0200
>     From:        Tobias Nygren <tnn%NetBSD.org@localhost>
>     Message-ID:  <20190722122335.55c0d421a18a082c8d67b6f1%NetBSD.org@localhost>
> 
>   | Please exercise caution when changing established userland behaviour.
>   | This change broke the pkgsrc/lang/openjdk8(1) build.
> 
> I stand behind my previous reply, if that change seemed to break
> anything, then all it was really doing was revealing previous brokenness.
> 
> However, as well as saying that printf(1) has no options, and (by omission)
> also saying that it should not do getopt processing, POSIX also says
> that if the format arg (ie: the first arg) contains no % cpnversions,
> and yet there are more args (which more or less by defnition can never
> be used) then the results are unspecified.
> 
> If what is, I am guessing, the "established userland behaviour" was
> 	printf -- format args
> which is truly pointless  (and incoorrect), but used to be accepted,
> then we can continue to allow that to work, relying upon that
> unspecified results clause from POSIX, "--" contains no % conversion,
> yet there are more args that nothing would normally ever consume
> (technically that format string is supposed to be used over and over
> again until the args are all used up ... but obviously that would never
> happen in this case - which is why it leads to unspecified results).
> 
> I intend to commit a change to printf in a few minutes to make it work
> like this (with the caveat that the "no % conversions" test will be "no
> % characters" which guarantees no % conversions of course, but is
> simpler).
> 
> If there is only one arg, it will always be treated as a format, so
> 	printf ---\\n
> will continue working as it should, or if the arg contains a % char,
> then it will also be treated as a format, so
> 	printf -%d\\n 3
> will print -3 as it should (neither of those wworked until recently).
> 
> This doesn't mean that whatever script in the openjdk8 build was using
> printf incorrectly shouldn't be fixed ... it should still be.
> 
> kre

Hi,

This sounds like a reasonable compromise in the interest of preserving
compatibility with other implementations. Thanks!

-Tobias