Path: utzoo!attcan!uunet!lll-winken!lll-tis!helios.ee.lbl.gov!pasteur!ucbvax!ulysses!hector!jss From: jss@hector.UUCP (Jerry Schwarz) Newsgroups: comp.std.c Subject: Re: 0x47e+barney not considered C Message-ID: <10413@ulysses.homer.nj.att.com> Date: 30 Jun 88 16:01:49 GMT References: <120200001@hcx2> Sender: netnews@ulysses.homer.nj.att.com Reply-To: jss@hector (Jerry Schwarz) Organization: AT&T Bell Labs, Murray Hill Lines: 48 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