0x47e+barney not considered C

Doug Gwyn gwyn at brl-smoke.ARPA
Mon Jul 4 04:28:05 AEST 1988


In article <8807030058.AA18406 at explorer.dgp.toronto.edu> hugh at dgp.toronto.edu ("D. Hugh Redelmeier") writes:
>I too submitted a comment on this in the last public review period,
>and mine too seems to have been ignored
>(I have not received the response document).

I assure you that none of the public comments were ignored.
The response document should arrive "soon", last I heard.
Meanwhile, here's the raw formatter input for the committee
response to your comment on this issue:

P24	88-054	3	33/36	3.1.8	N	\fIPreprocessor number\fP
						is too greedy.
'\" N:	The Committee discussed this proposal but decided against it.
'\"
The behavior pointed out is admittedly surprising,
but the Committee feels that this area is sufficiently complex
that trying to fix this particular case is very likely to lead to
surprises in other related areas.
Neither proposed solution is acceptable to the Committee.
The first proposal defines preprocessor grammar elements
by means of elements of the C language proper.
The second proposal would cause the number \f\*(cW1e4+6\fP
to be accepted as one preprocessing number,
which is behavior as surprising as that noted in the comment.

As I said earlier, this is not official (the hardcopy document
you receive will be), and you may well consider the response
to be inadequate, in which case you'll have 15 days after
receipt of the official response document to reply to that effect.

>Furthermore, Jerry thinks the problem does not warrant a fix.

That wasn't the impression I got.  I think everyone in this
discussion so far has agreed that the current specification
needs to be fixed to allow obviously correct constructs.

>As I understand it, most committee members saw most comments for the
>first time during the meeting (I am a member; I got only the early
>comments in a mailing).  Since the meeting is a very busy period,
>most comments could not have been read by very many committee
>members, and certainly not read very carefully.

Yes, that is essentially correct.  The tight schedule made it
difficult, in my opinion, to do justice to the second round
comments (which was the basis for my "no" vote).  They all did
receive consideration from at least a handful of committee
members, and in many cases that was sufficient since the issue
had been previously settled.  Questionable issues were brought
before the full committee.  A few public comment letters (for
example, ones dealing with internationalization or floating-
point issues) had suggested responses prepared in advance by
committee members with special expertise in the technical area;
even in those cases a committee subgroup discussed each issue.
I think proper procedure was followed; there just wasn't enough
time to study all comments carefully in advance.

I urge second round commentors to check the official responses
when they receive them to ascertain whether the committee appeared
to understand the essential point of each comment.  (However,
just because a suggestion was not adopted does not mean that it
wasn't understood!)  Just see whether the response makes sense.
Two committee members did review the responses, and in a few
cases modified the responses when they seemed inappropriate, but
we might have missed a few things..



More information about the Comp.std.c mailing list