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

[Glenn Golden]

--
Yes boys and girls, it's Monday, time again for our next episode of...
POSIX Pedantry...

We left our intrepid heros poised on the edge of conformance eternity, with
Eric suggesting that Glenn raise various questions on the POSIX mailing list...

I did so, initially just asking about the interpretation of "cannot use" and
its history in the spec.  Once they responded to that, we got into more detail
on the background and motivation that led to that question, i.e. what we've
been discussing here:

    http://news.gmane.org/gmane.comp.standards.posix.austin.general

The topic subject is "Seeking interpretation of 'cannot use' in Section 9.5.3"
dated 2013-10-09 19:00:05 GMT.

Two people responded: Mark Ziegast of Shware Systems, and Geoff Clare from
OpenGroup.

Here's a summary of the discussion, as best I understand it: ["POSCOR" below is
shorthand for POSIXLY_CORRECT.]

 * Regarding the initial question about the semantics of "cannot use": Their
   interpretation seems to accord with the straightforward semantic that I had
   suggested here, which amounts to: If you accept x > P as input and do
   anything with it other than rejecting it, then you are "use"ing it; hence
   "cannot use" is effectively synonymous with "must reject".

   On this topic, neither Mark nor Geoff expressed any sense of unease or
   murkiness about that interpretation. 

 * Regarding the semantics of the last sentence of XBD 9.5.3 in its entirety,
   in view of my question asking about the history of how it came to be worded
   as it is: After examining the history, Geoff's take is that the leading
   phrase "Conforming applications..." is just plain wrong, and has been since
   c. 2001.  In concert with the straightforward interpretation of "cannot
   use", it effectively declares -- as I've been opining -- that any 
   application which fails to reject extended EREs as input is unconditionally
   non-conforming. 

   Mark agrees it is wrong, but disagreed mildly with Geoff as to how it ought
   to be fixed.  Geoff suggested simply adding the qualifier "strictly".
   Mark's approach [2013-10-12 09:50:10 GMT] is to be more specific, stating
   explicitly that apps which expose x > P constructs to the user, while not
   strictly or generally conforming, can be conforming in the more restricted
   sense of XBD 2.2.3, as long as they meet the associated documentary
   requirement.  (As I understand it, the documentary requirement is to list
   the x > P constructs accepted by the application.) If not documented in
   this way, then the app is considered non-conforming.

Assuming you accept the above as authoritative for our purposes here, here
are some follow-on observations:

 - Since "cannot use" has the straightforward interpretation I'd suggested,
   my earlier conclusions based on that interpretation are valid.  However,
   those conclusions are now totally irrelevant because the remaining text of
   the offending sentence has been wrong since 2001. :) There is amusement
   value here, I hope you're chuckling. 
   
 - The new (corrected) text for the last sentence of 9.5.3 essentially
   inverts its original meaning, rendering it sensible: The original text
   said that no application accepting x > P could be conforming, period.
   The corrected text implies that "almost any" application accepting x > P
   _can be_ conforming [per XBD 2.2.3], provided that it documents the set
   of x > P which it accepts. (And, of course, apps accepting x > P cannot
   claim strict conformance, but there was never any debate about that.)

 - As to how the above pertains to GNU grep, IMO: Well, the present [wrong]
   text, in concert with the interpretation of "cannot use" implies clearly
   that every application based on GNU grep since c. 2001 has been non-
   conforming, unless it had explicitly pre-filtered those x > P and rejected
   them before handing them to grep, which of course no one ever does.

   But!

   That historic (and present) non-compliance is now irrelevant, since it
   isn't what the spec intended to say. :)

   Nevertheless, in my own defense as a fussbudget, it does justify the
   reasoning that led to this thread in the first place, including the claim
   that there is at minimum a doc issue [w.r.t. POSCOR] and perhaps a
   conformance issue [w.r.t. the original, wrong, text].

   No need to dwell on this (unless you wish to) since it will soon be
   obviated by the corrected spec text. But at least I feel now like a
   vindicated fussbudget rather than a plain vanilla fussbudget.

As to where to go from here: Once the corrected language makes it to draft
form (from which it can be cited in the man page) I'll take it as an action
item to submit a doc patch against grep.1.

The patch will discuss the conformance issue in detail, including the app vs.
imp duality, and we can hash it out here. But honestly I doubt you'll find
much to argue with, as it simply states the facts.  It carefully makes the
point which you guys have made here that there is no "defect" in GNU grep's
implementation simply because it does not reject x > P when POSCOR is set,
and explains why that is so.

But it will also state, per the [corrected] spec, that apps based on GNU grep
cannot be strictly or generally conforming unless they explicitly pre-filter
x > P (since GNU grep presently has no means to do that) but can be conforming
per XBD 2.2.3 provided that they list those x > P accepted by GNU grep.
(Prior to the spec correction, that last phrase ["...but can be conforming..."]
was not possible to write; and that was the core issue that brought this
thread up in the first place.)

In short, the reader will come away with a clear understanding of how the
use of GNU grep in his application relates to its POSIX conformance.

That doc patch, along with the spec change, will, IMO, be a constructive and
positive outcome of the entire conversation. I hope that you agree, and I tip
my hat to you both in supporting/putting up with a discussion in which a
contentious issue was hashed out constructively to positive result.