On Tue, 23 Jul 2019 00:31:32 +0700 Robert Elz <k...@munnari.oz.au> wrote:
> Date: Mon, 22 Jul 2019 12:23:35 +0200 > From: Tobias Nygren <t...@netbsd.org> > Message-ID: <20190722122335.55c0d421a18a082c8d67b...@netbsd.org> > > | 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
