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

[Glenn Golden]

--
Eric Blake <address@hidden> Sat, 28 Sep 2013 17:17:50 -0600:
>
> the intent of POSIXLY_CORRECT is only to change behavior where we do
> not comply with the requirements by default.
>

OK, that's a good start at clarifying the intent of POSIXLY_CORRECT, and glad
to see it.  IMO it would be worthwhile for us to hash this out further, if
you're not against doing so, since it has (to me) always been a bit ambiguous
as to what it implies in specific tools. Maybe others would benefit from it too.

>From your response, it seems that the central question is whether there is or
is not a conformance issue. So in what follows I will leave out any discussion
of how one might deal with non-conformance (via envars, etc, as mentioned in
my original posting and your response) and just concentrate solely on the
conformance question.

To summarize our views: I suspect (but am not sure) that there is a compliance
issue; you emphatically believe there is not:

>
> It's definitely NOT a POSIX conformance issue.
>

You've made your case in part by the following:

>
> You have to prove that we are mishandling input that is well-defined by
> POSIX before we have non-conformance.
>

I agree with the above, but only if you replace "have to" with "it is
sufficient to".  "Have to" implies that it is _necessary_ to prove mishandling
in order to demonstrate non-conformance.  I disagree, and claim that it is only
sufficient, not necessary.  In other words, showing mishandling of a POSIXly
well-defined input is one way to demonstrate non-conformance, but not the only
way.

I'll try now to make the case that there is another way to show non-conformance,
and I'll try to be more careful than I was in the original post. You're going
to hate me for what follows, so let me preface it with a few observations from
my own experience with IEEE standards so you'll hopefully hate me less. :)

The intent of being as punctilious as I'm about to be is not to be an
asshole -- though I suspect you may disagree :) --  but to minimize
contaminating the discussion with personal opinions, personal preferences,
or playing of word games. Just a step by step logical progression with an
earnest intent to get to the bottom of an issue on which two reasonable people
disagree.  Having spent many years involved in IEEE standards activity
(802, nowhere near POSIX) my experience has been that this even though
exercises like this may seem ridiculous and time-wasting, the plus side is
that when you finally finish, you wind up either coming to a mutually agreeable
conclusion which can be logically justified in view of the standard and common
sense, or you wind up identifying sloppy language or logical faults within the
standard.  Either of those is a useful result.  So please bear with me.
(But by all means enjoy it for its amusement value. :)

In what follows, 'grep' means GNU grep 2.14 (but probably applies to many
earlier versions as well).

Begin by asking some questions, answering each as best I can in view of the
standard, and using ordinary reasoning:

   1. Is grep a computer program?                       yes

        Self-evident

   2. Does grep perform some desired function?          yes

        Self-evident

   3. Is grep an 'application' as defined by POSIX:     yes

        3.17 Application: A computer program that performs some
        desired function

   4. Does grep 'use' the ERE '*xyz'                    yes

        Regardless of the state of POSIXLY_CORRECT, grep -E accepts '*xyz' as
        a valid input, performs a well-defined operation based upon it, and
        produces a well-defined result. I can't come up with any non-tortuous
        interpretation of the word "use" that allows one to say with a straight
        face that "grep cannot use the ERE '*xyz'". So my conclusion is that
        grep _can_ use '*xyz' (and can do so regardless of POSIXLY_CORRECT).
        

   5. Is grep a 'conforming application'                no

        Per the final sentence of 9.5.3, "conforming applications cannot use
        [constructs like '*xyz']".  By a well known rule of logic -- modus
        tollens, to be pretentious --  if A implies B, then !B implies !A.
        Define statements A and B as follows:

            Statement A:  "application X is conforming"
            Statement B:  "application X cannot use ERE '*xyz'"

        Implication: (Application X can use '*xyz') implies (application X
            is not conforming);

        Conclusion: grep is a non-conforming application.

Now let's ask what is probably the more relevant question: Can an application
which is non-conforming be part of a conforming implementation?

And here, I am at a loss for any satisfying answer which does not either become
quickly bogged down in silliness or does violence to common sense. This is why
I say I'm not sure if there is a conformance issue or not.  Really, it seems
like sloppy language.

On one hand, the standard seems to want to draw a line between "programs which
are part of an implementation" and "programs which are applications". But on
the other hand, it defines "utility program" and "application" in ways which
makes it impossible to deny that a program like grep is both a component of
"an implementation" and simultaneously "an application".

So I turn it over to you and hope for a detailed reasoning similar to the
above, either refuting that grep is a non-conforming application, or accepting
it and addressing the question of conforming application vs. conforming
implementation.