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

From: Eric Blake <[email-masked]>
Date: Mon, 07 Oct 2013 11:05:09 -0600

On 10/07/2013 10:53 AM, Glenn Golden wrote:

> The sentence is transformed into a logically equivalent form, and a free
> variable "X" is introduced. Finally, "grep" is substituted for X, and the
> deductive conclusion --  following from the transformed sentence and prior
> deductive steps -- is that grep, when considered as an 'application', cannot
> be considered to be a 'conforming application'.

So what?  No one cares whether grep is a 'conforming application', so
long as it can be used correctly as part of making a conforming
environment. Our counterargument is that we KNOW that grep in not a
conforming application, and WE DON'T CARE.  What we DO care about is
that in a conforming environment (where POSIXLY_CORRECT is set in the
environment), then grep behaves as required by POSIX for all
well-defined semantics, and that extension semantics are unaffected by
POSIXLY_CORRECT.

> 
> In short, it seems to me straightforward deductive reasoning, free of any
> assumptions at all.
> 
> If you still don't buy this, can you be more explicit about what led you to
> conclude that this assumption was being made?  I'm not being intentionally
> obtuse just to avoid your argument. If there's an argument there I'd like to
> understand it, but honestly just don't see it.

You're arguing about grep being non-conforming as if it mattered, but
our counterargument is that it does not matter.

> 
> To handle the input queries, we choose the extended regex engine from gnulib.
> This engine accepts extended EREs like '*xyz' and others from the bullet list
> in 9.5.3 which are disallowed by the reference grammar.

Being disallowed by the reference grammar does NOT imply that such regex
must cause an error.  POSIX is perfectly clear that implementations may
provide extensions that give non-error meaning to any regex that is not
strictly defined in the narrow subset required by POSIX.

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