🚀 go-pugleaf

In article <120200001@hcx2> tom@hcx2.UUCP writes:
>
>
>Prior to the introduction of pre-processing numbers (which, according
>to the rationale, were introduced to `simplify' the definition of
>tokens) I had always assumed that a pre-processing token consisted of
>the longest valid prefix of a token according to the fairly
>unambiguous definition at the front of the standard. I made this rash
>assumption because it was sensible, easy to implement, well defined,
>and only caused confusion when someone was doing something that was
>just asking for trouble.
>

Although I am not a member of the committee, I have seen many of
their working drafts and do not believe that there was ever any such
definition.  Nor do I believe it was ever the committee's intention.
Before the introduction of pp-numbers there was always a comment
about 1ex being an "illegal token" not two tokens. 

The rule you suggest is a bad one because it does not provide an an
easy way to extend the syntax of numbers.  For example, if I have an
implementation with a "long long" type  I might want to allow 6LL as
an integer constant of that type. Under the "longest legal prefix"
rule I can't. It gets tokenized as "6L" "L".  

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

As the author of the comment (during the first public review period)
that proposed pp-numbers I resent the implication of the preceeding
paragraph. I anticipate an apology.

The earlier drafts were ambiguous about several lexical issues,
especially about the interactions between tokens and pp-tokens.   The
current proposal is not.  The main motivation was to clean up
issues surrounding things like the "1ex" question.  

I believe an explicit syntax for pp-numbers is required.  The "0xe+b"
example points to a flaw in the current definition. But, in my
opinion, it is a minor flaw and does not require a change at this
stage in the standardization process.

Jerry Schwarz
Bell Labs, Murray Hill

In article <120200001@hcx2> tom@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!

jss@hector.UUCP writes:

>Although I am not a member of the committee, I have seen many of
>their working drafts and do not believe that there was ever any such
>definition [longest valid prefix].

You are absolutely right, there never was, as I said, it was a rash
assumption on my part because the area of "What is a token?" needed a
definition and that was the only one I could imagine that made any
sense. The area definitely needed defining, and preprocessing numbers
are certainly better than the complete lack of definition that existed
before. [Feel free to consider this an apology].

>The rule you suggest is a bad one because it does not provide an an
>easy way to extend the syntax of numbers.  For example, if I have an
>implementation with a "long long" type  I might want to allow 6LL as
>an integer constant of that type. Under the "longest legal prefix"
>rule I can't. It gets tokenized as "6L" "L".  

This does not make sense. If I am extending C with new features and I
make LL a valid suffix, then I have changed the definition of what a
valid token *is*, so I would not tokenize 6LL as 6L L, but as 6LL.
Obviously, I may have problems if some twisted programmer somewhere
has previously written code which tries to take advantage of the 6L L
tokenization by making L a macro that expands to +5 or something, but
I am not sure I care much, because on the other side of the coin, I
can probably port your code that uses 6LL to my system by just
defining L to the empty string.

And gwyn@brl-smoke.UUCP writes:

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

Yeah, you're right, I haven't gotten it yet, although I did get a nice
letter telling me that I haven't gotten it yet.

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

I guess I just don't care what happens to ``garbage'' when the
alternative definition in the standard turns ``sensible'' C into
``garbage''.

>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;

Goodness gracious no. My proposal of longest valid prefix would parse
0x47e+barney into 0x47e + barney NOT 0 x47e + barney. The point is
that the definition of preprocessing numbers calls 0x47e+barney a
SINGLE token. This means it will be treated as a single unit all the
way up until it is converted to a token.  The standard says that
behavior is undefined if a pp-token cannot be converted to a token,
this (presumably) gives an implementation the right to convert this
single pp-token "0x47e+barney" into the three tokens "0x47e" "+"
"barney", but the major problem is that "barney" might have been a
macro. It is now too late to expand it.

Obviously, there is no reason to actually remove pp-numbers at this
point in the evolution of the standard, it would be too big a change.
But I do feel that the definition should be changed to allow something
that is currently perfectly legal C to remain legal. The real problem
is that is is actually fairly hard to write the grammar so that it
works. For what it is worth here is an attempt:

           pp-hex-prefix:       (the two chars that can start a hex number)
                   0 x
                   
           pp-not-hex-prefix:   (the things that can start other numbers)
                   . digit
                   digit .
                   digit digit
                   digit e sign
                   digit E sign
                   digit nondigit-except-x
                   
           pp-number:           (single digits, or hex or not-hex pp numbers)
                   digit
                   pp-hex-prefix
                   pp-not-hex-prefix
                   pp-hex-prefix pp-hex-suffix
                   pp-not-hex-prefix pp-not-hex-suffix
                   
           pp-not-hex-suffix:
                   digit
                   . digit
                   pp-number digit
                   pp-number nondigit
                   pp-number e sign
                   pp-number E sign
                   pp-number .
           
           pp-hex-suffix:
                   digit
                   pp-number digit
                   pp-number nondigit

I think that does it, but I can't be sure. A pp-number is now a number
that starts with "0x" and is followed by any number of digits or
letters, or it is a number that starts with something other than "0x"
and contains all the stuff the current pp-number definition has
(decimal points, e+, E+, e-, E-, letters).

With this definition 0x47e+barney will now parse as 0x47e + barney and
6LL will still parse as 6LL.

It sure seems like it ought to be possible to simplify this grammar.
Do I hear any alternate definitions? Or should the committee just
leave the grammar the way it is and stick in some language about
leading 0x not allowing the e+ e- stuff?  Also I took out '.' as long
as I was splitting the definition by prefix, but if someone has a good
reason to leave '.'s in hex pp-numbers I don't much care. It is the e+
that causes all the trouble. I would really like this fixed for the
final standard and something that could be considered an editorial
change is probably the only thing that stands a chance.

P.S. I am glad to see that stuff I post can actually make it out to
the net.

=====================================================================
    usenet: tahorsley@ssd.harris.com  USMail: Tom Horsley
compuserve: 76505,364                         511 Kingbird Circle
     genie: T.HORSLEY                         Delray Beach, FL  33444
======================== Aging: Just say no! ========================

In article <120200001@hcx2> tom@hcx2.SSD.HARRIS.COM writes:
| 
| I tried posting a comment about this before, but never got any
| responses, so I suspect it became trapped in a maze of twisty little
| passages in our local net without reaching the world at large.
| 
| To get your attention right away, I will point out the following
| true fact:
| 
|       fred = 0x47e+barney ;
| 
| Is NOT a legal Ansii standard C statement. It contains a lexical
| error.

  If the standard really says that this is not legal C the standard is
broken, not the program. The language was changed once to replace
operators like "=*" with "*=" to avoid nonsense like this. I assume that
the standard is poorly stated rather than intended to break existing
programs, but after introducing trigraphs into an *American* standard to
make the language acceptable *elsewhere*, I wouldn't bet on it.

  At the early meetings the committee expressed a desire to "codify
existing practice without egregiously breaking existing programs."
Obviously the desire to be inventive has modified that somewhat.
-- 
	bill davidsen		(wedu@ge-crd.arpa)
  {uunet | philabs | seismo}!steinmetz!crdos1!davidsen
"Stupidity, like virtue, is its own reward" -me

In article <10413@ulysses.homer.nj.att.com> jss@hector (Jerry Schwarz) writes:

| I believe an explicit syntax for pp-numbers is required.  The "0xe+b"
| example points to a flaw in the current definition. But, in my
| opinion, it is a minor flaw and does not require a change at this
| stage in the standardization process.

  I hate to say this, but a bad standard which breaks existing programs
should not be rushed out the door, even if everyone is tired of working
or waiting on it. If it breaks existing programs, there better be a
better rationale than the convenience of the compiler implementors. If
this really was the intent that hex number ending in e can't be followed
by a variable, then I don't see any rationale at all. If the wording is
poor it should be changed.

  Was it intended that exponentiol value be allowed on hex (and I assume
octal) values? If so, how about fractional values, such as "0x1ea.b", or
even worse "0x1ea.e+2"? Is the final e a fractional part or an exponent?

  I will assume that the committee intended this to work as it always
has, and not have a program which will fail if there is no whitespace
somewhere. This should just be an editorial change.
-- 
	bill davidsen		(wedu@ge-crd.arpa)
  {uunet | philabs | seismo}!steinmetz!crdos1!davidsen
"Stupidity, like virtue, is its own reward" -me

In article <8194@brl-smoke.ARPA> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes:

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

  Regardless of what X3J11 is entitled to do, it would be foolish to let
a mistake like this go through. "entitled to ignore" seems to be a
poorly chosen way of putting it.
-- 
	bill davidsen		(wedu@ge-crd.arpa)
  {uunet | philabs | seismo}!steinmetz!crdos1!davidsen
"Stupidity, like virtue, is its own reward" -me

In article <8194@brl-smoke.ARPA>, gwyn@brl-smoke.ARPA (Doug Gwyn ) writes:
> Is it that "0x47e" is supposed to be split into preprocessing tokens
> "0" and "x47e" ...

Oops, Dave Prosser straightened me out on this.  When I looked at the
pp-number grammar in section 3.1.8, somehow the construction
	pp-number:	pp-number nondigit
did not register.  Perhaps my eyes saw it but my mind refused to
believe what I saw.

Anyway, the problem is that the pp-number syntax is TOO greedy, not
(as I feared) that it was insufficiently broad.

Although it is somewhat annoying to realize that
	123zzz456
is a single valid preprocessing token, that wouldn't really matter
so long as it became invalid in translation phase 7, as in fact it does.
The truly serious problem is that
	0x47e+barney
or even
	0xE+0x10
appears to be invalid C because of this error in specification; it's
turned into a single token in phase 7 instead of the three tokens one
might expect.  I don't know a simple way to fix this (which certainly
was unintended), but probably other X3J11 committee members can figure
out how.  This does deserve a re-response and committee reconsideration.

In article <11445@steinmetz.ge.com> davidsen@crdos1.UUCP (bill davidsen) writes:
>In article <10413@ulysses.homer.nj.att.com> jss@hector (Jerry Schwarz) writes:
>
>| I believe an explicit syntax for pp-numbers is required.  The "0xe+b"
>| example points to a flaw in the current definition. But, in my
>| opinion, it is a minor flaw and does not require a change at this
>| stage in the standardization process.
>
>  I hate to say this, but a bad standard which breaks existing programs
>should not be rushed out the door, even if everyone is tired of working
>or waiting on it. If it breaks existing programs, there better be a
>better rationale than the convenience of the compiler implementors. If
>this really was the intent that hex number ending in e can't be followed
>by a variable, then I don't see any rationale at all. If the wording is
>poor it should be changed.
>

My purpose in proposing pp-numbers was ease of understanding of the
rules. That would frequently make it easier to implement, but that is
a happy side effect not the motivation.

I suppose "rush" is a subjective notion, but given the time that has
elapsed since the committee began work nothing that emerges at this
point would seem rushed to me.

If you believe that any standard that breaks any existing program is
bad then I'm afraid you will have to accept a bad standard.  There
are several points at which the current proposal may break existing
K&R programs.  See the "silent changes" discussed in the rationale.

>  Was it intended that exponentiol value be allowed on hex (and I assume
>octal) values? If so, how about fractional values, such as "0x1ea.b", or
>even worse "0x1ea.e+2"? Is the final e a fractional part or an exponent?
>

I can't speak to what the committee believes, but my intention when I
proposed pp-numbers was that all of these are pp-tokens.  They are
not, however, legal tokens.  Because they are illegal tokens it makes
no sense to ask what the "." or the "e+" are. As I pointed out in my
earlier note, the committee has always had a vague notion of "illegal
token".  The syntax of pp-number is intended to be part of the
formalization of that notion. Any change for "0xe+y" should not change
the status of the above.

>  I will assume that the committee intended this to work as it always
>has, and not have a program which will fail if there is no whitespace
>somewhere. This should just be an editorial change.

Whitespace has always been required in some contexts.  A well known
example is "x+++++y"  versus "x++ + ++y".

In article <120200001@hcx2> tom@hcx2.UUCP points out that under the
draft ANSI standard for C, preprocessor numbers are too greedy.
He gave the example of

	0x47e+barney

which is parsed as a preprocessor number, and then rejected when it
cannot be converted to a legitimate C token.  He is correct, and I
agree with him in considering this a mistake.  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).

In article <10413@ulysses.homer.nj.att.com>, Jerry Schwarz says that
Tom's article insults his construct, the pp-number, and that Tom's
fix is bad.  Furthermore, Jerry thinks the problem does not warrant a
fix.

I think that the pp-number construct did clean up a mess (which I
too had been pointing out for a while).  But it can and should be
fixed to not break formerly valid and perfectly reasonable C
programs.

In article <8194@brl-smoke.ARPA>, Doug Gwyn asks:

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

For me, the problem is that the +barney is absorbed into the hex
constant.  The + clearly ought to be a separate token, and so should
the barney.

Here is what I submitted to the committee in the previous round:

Page 33, line 36, Section 3.1.8:
preprocessor number too greedy (consider 0xABCDE+1)

The current rules for parsing preprocessor numbers are too greedy.
They are willing to match + or - after an e or E.  If the e came
from a floating point number, that is fine, but if it came from a
hexadecimal number, it is not.  Consider the following examples:

	0xABCDE+1
	0xABCDE+cat

	0xABCDEF+1
	0xABCDEF+cat

The first two lines used to be legitimate C expressions.  Now each
is a pp-number that cannot be turned into a valid C token.  The
second two lines were and remain legitimate expressions.

Although I think that the whole concept is wrong, it can be patched
up to solve this problem.

Proposed grammar:

pp-number:
	integer-constant
	floating-constant
	pp-number digit
	pp-number nondigit
	pp-number .

I find this definition intuitively appealing: it reflects what is
really going on.  Others may prefer one that is simpler to implement:

Alternate grammar:

pp-number:
	pp-floating-constant
	pp-number digit
	pp-number nondigit
	pp-number .

pp-floating-constant:
	digit
	. digit
	pp-floating-constant .
	pp-floating-constant digit
	pp-floating-constant e sign
	pp-floating-constant E sign

Note that in pathological cases, these differ.  Consider:

	1.1.e+5

----------------------------------------------------------------

Further notes on Doug's comments:

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

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.

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

I think that you put it well, and very diplomatically (perhaps too
diplomatically).

Hugh Redelmeier
{utcsri, utzoo, yunexus, hcr}!redvax!hugh
In desperation: hugh@csri.toronto.edu
+1 416 482 8253

In article <8807030058.AA18406@explorer.dgp.toronto.edu> hugh@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..

Somebody pointed out a while ago that whitespace is sometimes needed in
programs.  For instance,

   a / *p

is not the same as

   a/*p



So type   0x47e + barney.

And smile.
-- 
                 Gordan Palameta
            uunet!mnetor!maccs!gordan

In article <1287@maccs.McMaster.CA> gordan@maccs.UUCP () writes:
| Somebody pointed out a while ago that whitespace is sometimes needed in
| programs.  For instance,

| [ ... instance deleted ... ]

| So type   0x47e + barney.
| 
| And smile.
 And don't EVER use a pretty formatter again, because the option to
delete whitespace may be on. Maybe we should put (parenthesis)(on)
(every)(token).

It sounds as if the response is that the fix is complicated, so it won't
get done.
-- 
	bill davidsen		(wedu@ge-crd.arpa)
  {uunet | philabs | seismo}!steinmetz!crdos1!davidsen
"Stupidity, like virtue, is its own reward" -me

[If you see this article twice, my apologies]

The important question that hasn't been mentioned is this:

    How do existing compilers treat 0x47e+barney?

If -- as I would guess -- it is generally accepted, then the Standard should
accept it, and the current Draft needs a fix.

Without deep consideration I can't see why preprocessing numbers can't just
be assigned the same syntax as ordinary numbers.  Can't we have something
like
	preprocessing-number:
		floating-constant
		decimal-integer-constant
		hex-integer-constant
etc.?
(I'm winging this, but you get the idea.)

Mark Brader, Toronto		sed -e "s;??\\([-=(/)'<!>]\\);?\\\\?\\1;g"
utzoo!sq!msb, msb@sq.com	will fix them...	-- Karl Heuer

> Without deep consideration I can't see why preprocessing numbers can't just
> be assigned the same syntax as ordinary numbers...

Well, speaking as someone who has implemented a C lexical analyzer, I was
very happy when preprocessing numbers arrived.  Without them, you have to
implement lexical analysis of C numbers -- which are a baroque mess --
*twice*.  Why?  Because a lot of validity checks that are needed for real,
live numbers cannot be applied to preprocessing numbers, since abominations
like the # and ## operators may alter the tokens before the preprocessor
is finished with them.  Short of storing numbers in some complex broken-
down form -- and remember that those same two operators require that the
original text be recoverable! -- there is just no way to avoid repeating
the whole ugly lexical analysis when you've got the final tokens on hand.

Personally, my favorite solution to this involves eliminating the # and
## operators, by saturation thermonuclear bombing if nothing less will
kill them, but not everyone likes this idea.