[illumos-Developer] webrev: printf

Thu Oct 14 11:51:26 PDT 2010

On Thu, 2010-10-14 at 14:16 -0400, Kyle McDonald wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>  
> 
> 
> On 10/14/2010 1:56 PM, Garrett D'Amore wrote:
> > On Thu, 2010-10-14 at 19:39 +0200, Nicholas George wrote:
> >> The VSC license prohibits distribution of the source but AFAIK
> >> describing the tests is OK.
> >> Test 19 passes - followed by [a-zA-Z] as options and probes stdout for
> >> these strings to show up there. The test fails if >=27 iterations all
> >> pass the strings in stdout.
> >
> > I would argue that this test doesn't test what the *standard* says. The
> > standard was pretty clear, you have to handle "--", but beyond that, any
> > option arguments are implementation defined behavior. What's wrong with
> > my assertion that the implementation defined behavior for each of these
> > is to print "-", followed by the option letter itself, and treat the
> > remaining option data as the format?
> >
> Whether that is right or wrong, I imagine the 'and treat the remaining
> option data as the format' is wrong.
> 
> If you accept the -whatever as a non-option and are willing to print
> it, then shouldn't you also consider it the format string?
> 
> I read that thread on the bash-bug list, and the command that was
> being attempted there was
> 
> printf ----%s--- test
> 
> The standards person there said this should be an error, but lets say
> you want that to work, I don't think (unless I misunderstand your
> statement above) that what you're describing will. Won't your way
> print '----%s----' and then use 'test' as the format string? I guess
> that would look like:
> 
> - ---%s--- test
> 
> I don't think that's right no matter how you read the spec.

Actually, the above example *does* work in *both* my version, *and* in
stock ksh93.   bash rejects it.

Its possible that my explanation was wrong, but lets say that I want to
handle "--${variable}" as follows:

	printf("--");
	printf($variable, ...);

Now couldn't I assert the same behavior for "-a", "-b", and so forth?

I'd like to see a binding description of the Standard that prohibits
such behavior.

*My* read of the standard is that "--" needs to be treated as the end of
the option list, but as there are no options that have to be supported,
I'm not obliged to have any specific handling for other options.  The
text on this point was pretty clear, XCU chapt 1, the section that
covers OPTIONS describes "Default Behavior:"

http://www.opengroup.org/onlinepubs/009695399/utilities/xcu_chap01.html#tag_01_11

        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.

        The requirement for recognizing "--" is because conforming
        applications need a way to shield their operands from any
        arbitrary options that the implementation may provide as an
        extension. For example, if the standard utility foo is listed as
        taking no options, and the application needed to give it a
        pathname with a leading hyphen, it could safely do it as:

                        foo -- -myfile

        and avoid any problems with -m used as an extension.

Then the description of printf is actually very clear:

http://www.opengroup.org/onlinepubs/009695399/utilities/printf.html

OPTIONS indicates "None."

The VSC tests are incorrect.

	-- Garrett

> 
> Again, I may be missing something somewhere!
> 
>   -Kyle
> >> Test 21 passes -\# and -\\ as option. Neither # and \ are portable
> >> option characters. If both appear in stdout the test fails.
> >
> > So its verboten to handle any non-portable option characters as part of
> > your implementation specific behavior? Where is *that* specified in the
> > standard?
> >
> >>
> >> As final word to my contribution here: I see you already made the
> >> commit without waiting for the discussion to conclude. Based on the
> >> commit and your IRC comment that "pragmatism won here" I assume that
> >> POSIX and the Single Unix Standard will not play a key role in
> >> Illumos, which rule out Illumos as viable alternative to Solaris.
> >> I will recommend my employer, MBDA System Integration, to withdraw
> >> from Illumos and focus on Oracle Solaris 11 as host for our products.
> >
> > While that's your choice, I can assure you of this:
> >
> > a) illumos' implementation is *no* worse than Oracle Solaris 11's in
> > this regard (in fact its even better in some respects, not related to
> > the standard).
> >
> > b) the printf implementation I just integrated *can* change, if there
> > is sufficient cause to do so. Right now I don't hear sufficient cause.
> > (Given a choice I'd rather support broken scripts deployed in the field
> > than broken VSC tests. One of these directly affects users, the other
> > does not.)
> >
> > c) Oracle probably doesn't care about POSIX in the least. In fact, I
> > think Oracle has made it reasonably clear that the only ISV support that
> > they care about for Solaris 11 is Oracle itself.
> >
> > That said, go ahead and withdraw from illumos if you feel that's in your
> > company's best interests.
> >
> > - Garrett
> >
> >
> >
> >
> > _______________________________________________
> > Developer mailing list
> > Developer at lists.illumos.org
> > http://lists.illumos.org/m/listinfo/developer
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.14 (MingW32)
>  
> iQEcBAEBAgAGBQJMt0kDAAoJEEADRM+bKN5wuqgIAMVp2meL6FYqsxARaQiyxV+C
> Ra7gC0zTNaEPMbZkC6CjiSt6ae1HALgmnkPmSzJUCdbx0AlBNtc7DjZS8MYadxeK
> VyqYiQ9PE8ljm5cZ2Fj1gkBB+dLJs7xhwYDfqojgSrR5LRHON9JmhqmdlXH9RtQ7
> Jsi0EybmQ2xT8hpij0Vj2lXy486+ITTxNf+ClE4sFc3LykYxO3/D8DDpqAd+XHU/
> fD6TF0O3xKNbhpZcItKdDEpNNepwyMJjnQKIXA8EUlnICrKXKOy5HFjibyG4uqCu
> Zt7Sp23NA4XT6BD+R9A45wjPysZoZeYA1DmG+Pw8gYRWAWyqyXVk31t25n6Bn1A=
> =0xeb
> -----END PGP SIGNATURE-----
> 
> 
> _______________________________________________
> Developer mailing list
> Developer at lists.illumos.org
> http://lists.illumos.org/m/listinfo/developer