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

[Glenn Golden]

--
OK, if Wednesday is Prince Spaghetti Day, I guess Monday must be POSIX Pedantry
Day.  Seems to be a pattern developing...  :)

Anyway...  In the discussion below, the following notation is used, just to
avoid overloading certain words like "strictly" with meanings that seemed
(to me) ambiguous in some earlier posts:

  P             The set of EREs accepted by the grammar defined in clause 9.5.3
  x = P         Regex x is a member of P
  x > P         Regex x is an extension to P (hence not a member of P)
  grep          GNU grep, 2.14
  'blah'        Words/phrases well-defined within POSIX (single-quotes used).

Paul Eggert <address@hidden> [2013-09-29 16:53:21 -0700]:
> Glenn Golden wrote:
> > Per the final sentence of 9.5.3, "conforming applications cannot use
> >     [constructs like '*xyz']"
>
> This is making the incorrect assumption that 'grep' internally must be
> implemented as a strictly conforming POSIX application.
>

I looked over the reasoning step that you excerpted from above, and honestly
see no sign of anything that could be construed as an assumption of any sort,
about grep or anything else.

What's going on in that step is a straightforward analysis of a sentence from
the standard (last sentence of clause 9.5.3).

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'.

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.

In any case... Here's perhaps a better way to make the same point about the
final sentence of 9.5.3: Go at it initially without even considering grep;
purely from an application-writer's perspective.  This prevents complicating
the discussion with grep's [debatably] dual status as both a system 'utility'
and simultaneously as an 'application'. Bear with me, as I think this will
get to the core of the issue:

Suppose we decide to write a simple database application. It accepts a regex
as user-supplied input, extracts records from the database matching the regex,
then reformats the selected records in some fancy way, which becomes the
application's output.

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.  So, if a user queries
our app with an RE like '*xyz', the app interprets it in accordance with GNU
extended regex rules, and returns the matching records which we then format
and barf out.

Now we ask: Can our app, as described above, be certified as a 'conforming
application' (2.2.2)?

To answer, we need to examine all the 'shall' clauses in 2.2.2 to be sure we
comply with those. Let's say we do.  Now we also need an interpretation of the
last sentence of 9.5.3, which places a restriction on what a 'conforming
application' may do, and be sure that we _don't_ do that.

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.

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.)

Note that I'm not claiming that the above interpretation is Right; only that
it seems reasonable.

I checked the opengroup/IEEE site

    http://get.posixcertified.ieee.org/PR/

for any existing problem reports or interpretations on this clause. I found
none, but the site presently has numerous broken links, and it wasn't clear
the search feature was working properly. (I reported the issue to the site
admin like a good boy. :)

So before continuing with this line of reasoning, let me ask: Do you agree
with this interpretation?

If so, I'll continue.  If not, please explain a preferred interpretation. 
Understanding this is central to choosing text I'd submit for approval in
a doc patch (per Eric's suggestion to do so).