bug#15483: POSIXLY_CORRECT documentation vis a vis some simple EREs

[Eric Blake]

On 09/28/2013 11:52 AM, Glenn Golden wrote:
>         * One or more ERE_dupl_symbols appearing first in an ERE, or [ ... ]
> 
>     Implementations are permitted to extend the language to allow these.
>     Conforming applications cannot use such constructs. 

POSIX does not require implementations to diagnose undefined behavior,
and the intent of POSIXLY_CORRECT is only to change behavior where we do
not comply with the requirements by default.

> Not sure whether this is a POSIX conformance issue or not; it depends on the
> intended semantics of POSIXLY_CORRECT.

It's definitely NOT a POSIX conformance issue.  The question can still
be raised on whether it is a consistency issue with other GNU
applications on how POSIXLY_CORRECT is normally used, and whether it is
a documentation bug.

>    1. If POSIXLY_CORRECT is intended to be conforming only in the specific
>       respects listed, I'd suggest that the name of the associated envar be
>       changed to reflect that (e.g., something like POSIXLY_CORRECT_OPTS),
>       and also to change the man page text to read something like:
> 
>        POSIXLY_CORRECT_OPTS
>         If set, grep conforms with POSIX.2 with regard to the following
>           option processing behaviors: [ description of option behaviors ]

No, for two reasons.  1. The name POSIXLY_CORRECT is already entrenched,
and it's too late to add a new variable name for marginal value.  2.
POSIXLY_CORRECT only changes behavior if our default is saner than what
POSIX requires, but where you can request the POSIX behavior even though
it is arguably not as nice as the default.

> 
>    2. If POSIXLY_CORRECT is intended to mean 'fully conforming in all 
> respects'
>       then it seems like the present behavior is in technical violation.

Fully conforming is pretty broad.  POSIX does not require grep to
diagnose where your usage of grep is undefined.  It only requires that
if you stick to the subset of regular expressions that are well-defined
by POSIX, then the behavior matches what POSIX states.  We can do
whatever we think makes the most sense with input that is beyond the
subset required by POSIX, and still be a POSIX-compliant implementation
while doing so.

> 
>    3. If (2) is the case, and the decision is made to change the behavior of
>       grep accordingly, it might be worthwhile to also change the doc for
>       POSIXLY_CORRECT to something like this:

I don't see the need to change any behavior.  We are already POSIX
conforming, since POSIX already states that your input string is
non-compliant.

> 
>    4. If (2) is the case, but the decision is made not to change the behavior
>       of grep (i.e. accept the non-conformance) 

What non-conformance?  You have to prove that we are mishandling input
that is well-defined by POSIX before we have non-conformance.  But POSIX
doesn't require us to do anything in particular with undefined behavior
- we can reject it, we can silently ignore it, we can give it useful
semantics as an extension, or any number of other things, and still be
fully compliant.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

signature.asc
Description: OpenPGP digital signature