0x47e+barney not considered C

[Doug Gwyn]

In article <120200001 at hcx2> tom at hcx2.SSD.HARRIS.COM writes:
>Apparently the C committee spent a lot of time looking at the last
>case and decided that it was far more important to serve the needs of
>the contestants in the annual obfuscated C contest than it was to
>serve the needs of people who happen to have code in which a hex
>constant ending in e is added to something. Thus, the origin of the
>obscure and pointless `pre-processing number'.

Revisionist.  I don't remember quite how pp-numbers arrived,
but certainly it had nothing to do with this fanciful scenario.

>I pointed out this error in a formal response to the standard, but the
>committee was apparently too tired of arguing to do anything about it,
>as a result, they decided to leave pre-processing numbers alone.

Excuse me, but that was NOT the X3J11 committee's response to your
comment.  In case you haven't received the official response document
yet (which is possible due to confusion between CBEMA and X3J11 as to
who was supposed to do what), here is the raw input for the response
to that item in your comment letter:

P02	88-032	X1	6	3.1.8	PD	Eliminate preprocessing numbers.
'\"PD:	The Standard reflects the result of previous discussion of this issue.
'\"
Before the introduction of the \fIpreprocessing number\fP syntax,
the Committee had considered other proposals
similar to the one suggested in this public comment.
We were uncomfortable with preprocessing behavior that
could parse ``garbage'' into a sequence that contained an identifier,
which is then macro-replaced to form a ``sensible'' statement.
[END RESPONSE]

Now, it is entirely possible that you do not consider this to be
an adequate response, and you are entitled to respond to X3J11's
response within 15 working days after you receive the official
response.  (This posting is NOT official, nor are responses posted
here or mailed to committee members instead of X3.)  Should you send
a re-response, it would be added to comments from the third formal
public review currently underway (ending 1-Sep-1988) and would be
considered at the next X3J11 full committee meeting, which has been
rescheduled to late September.

>The best thing to do is get lots of complaints about this in to the
>committee during this next review period.

NO!  X3J11 will be entitled to ignore such comments from anyone other
than the original second-round commentor, since it has requested that
comments in the third formal public review be limited to remarks on
substantive CHANGES made as a result of the second public review.
(Of course, if the third public review document is really being
sent out without accompanying Rationale, as someone reported, it is
possible that the cover letter containing this restriction got left
out too.)

If X3J11 happens to decide that there is a significant technical
flaw in this area that is worth delaying publication of the Standard
for yet another six months in order to fix, then I expect that they
will do so.  Or, if the fix could legitimately be considered
"editorial", meaning that the committee really intended it all along
but didn't state the specification quite right, then perhaps this
could be fixed without delaying the final Standard.

Why do you think it so important for "0x47e" to be considered a
preprocessing number token?  Just what is it that needs "fixing"?
Is it that "0x47e" is supposed to be split into preprocessing tokens
"0" and "x47e" (the second of which may be subject to macro
replacement!) and in translation phase 7 they are not said to be
spliced back together into a single (regular) token, so that it is
impossible for an integer constant "0x47e" to ever be seen after
phase 6?  If so, that does seem to me to be a problem, but it has
nothing to do with "+barney" or with the final "e" on the constant;
it's a generic problem for all hex constants (and was certainly not
the committee's intention, so fixing this would presumably be
considered editorial).

P.S.  I don't think the committee was "too tired of arguing to
do anything about it".  More likely the review subgroup that
tackled your comments didn't fully understand the problem.  If I've
correctly summarized it in the previous paragraph, then try an
argument along those lines in your re-response.

P.P.S.  I was the only committee member who voted against sending
out the revised draft for the third public review, on the grounds
that there had been insufficient time allotted to study second-
round comments before responses were required.  This may be an
example of that.  I do think the committee did a remarkably good
job under the [self-imposed] circumstances.

P.P.P.S.  No, I did NOT purposely cause the next meeting to be
delayed long enough to give more careful consideration to third-
round comments, even though that's how it seems to have turned out!