Re: "conformance" vs. compatibility

[Paul Jarc]

Paul Eggert <address@hidden> wrote:
> It's up to your the coreutils installer (typically a software
> distribution maintainer) to specify the default value for
> _POSIX2_VERSION.

How is that controlled, exactly?  I think it ought to be documented in
README.

> So the compatibility problems that you mention occur only when the
> coreutils installer has indicated a desire to conform to the new
> standard by default (even when that is incompatible with the old
> standard).

IIRC, the indication comes from a macro definition in some standard
system header file.  But if that's true, then it is actually the libc
maintainer who has made the indication, not the coreutils installer.
Since we have so many libcs and utility packages to choose from in the
free software world, this strikes me as a bad idea - the maintainer of
any given libc cannot know which utility package their users will
choose, let alone what level of POSIX conformance that utility package
aims for.

If the choice is somehow truly under the control of the coreutils
installer, then I would be happier.

>>     One may argue that 'tail -35' does not result in a multi-digit
>>     option of 35, but rather a null option, with argument of 35.
>
> That's not how the guidelines work.  If 'tail' were to follow the
> guidelines, then 'tail -35', 'tail -3 -5', 'tail -5 -3', and 'tail
> -53' would all be equivalent.

Not necessarily.  It could instead be interpreted as, for example, the
option 3 with argument 5.  Item 2c of the Utility Argument syntax
rules allows for historical cases where the option and its argument
cannot be separated.  This does nothing for +n, but see below.

>>     To illustrate my position further, let's examine another way that
>>     these programs "violate" posix standards: long options.
>
> I don't see why they "violate" the standards.  A plain "--" argument
> cannot possibly be an option (since it is a standard delimiter), and
> therefore "-" cannot possibly be an option name.  Long options
> therefore are not part of the standard option syntax at all; they are
> a pure extension.

# Guideline 3:
#     Each option name should be a single alphanumeric character (the
#     alnum character classification) from the portable character set.

Long options are not single characters.  So they break the rules laid
down for options, and thus must be considered to be something other
than options if we want to say that they do not violate the standard.
But can't this be done just as easily for -n/+n?  We could simply call
them "operands" (or something else yet) instead of "options", and then
the fact that they do not obey the syntax rules for options wouldn't
matter.  I see no rule saying that every argument beginning with "-"
should be an option - but if there is one, then that would put long
options in violation too.

> Long options are clearly useful.  It's less clearly useful to
> support options that have been officially obsolescent for more than
> a decade, and have been officially obsolete for almost two years.

The usefulness of -n/+n comes from existing code and habit; official
pronouncements are irrelevant.


paul