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
