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

[Robert Elz <kre%munnari.OZ.AU@localhost>]

    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