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

[Eric Blake]

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

> Unfortunately, the standard seems to offer no insight as to what is meant or
> intended by "cannot use".  One interpretation, which seems non-tortuous to me,
> is as follows:
> 
>     * Conforming applications must not accept x > P as input.

Not true.  Rather, the intent of POSIX is that if an application is
presented x > P as input, then the application is no longer bound by the
rules of POSIX, and undefined behavior will occur.  That is, rather than
make your application worry about the diagnosis of x > P, you can
instead transfer the blame to the user that is passing you bogus input.

Remember, POSIX also says that strlen(NULL) is undefined behavior.  In
some implementations, it succeeds (generally with the value 0); in
others it fails by causing SIGSEGV.  But the whole point is that it is
undefined - the burden is on the user to not pass invalid input in the
first place, and not on libc to react in any particular manner to that
bad input.  The burden of strictly conforming is on the caller to not
provide bad input in the first place, not on what the receiver must (or
must not) do with input that is out of spec.

> 
> Or stated in a more practically actionable way:
> 
>     * If presented with an RE x > P as input, a conforming application must
>       diagnose it as fatal (i.e., declare it in error and refuse to continue.)

That is one possible action to take on undefined behavior, and might
even be a desirable behavior, but it is NOT required behavior, and does
not happen to be the current behavior of grep unless someone writes a
patch.  Remember, 'sed --posix' is an extension to POSIX where GNU sed
tries hard to diagnose extension inputs, and we would not be opposed to
such a patch for grep if it is easy to maintain; but I am also
personally unlikely to write such a patch.

If you still worry about what POSIX intends or not, it is probably
better to ask the actual POSIX list (<address@hidden>), as
they would actually be able to do something about it.  This list is
probably not the most effective place to argue about what POSIX intended.

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

signature.asc
Description: OpenPGP digital signature