Path: utzoo!attcan!uunet!husc6!bloom-beacon!tut.cis.ohio-state.edu!mailrus!ames!umd5!uflorida!novavax!hcx1!hcx2!tom From: tom@hcx2.SSD.HARRIS.COM Newsgroups: comp.std.c Subject: 0x47e+barney not considered C Message-ID: <120200001@hcx2> Date: 29 Jun 88 11:58:00 GMT Lines: 80 Nf-ID: #N:hcx2:120200001:000:3229 Nf-From: hcx2.SSD.HARRIS.COM!tom Jun 29 07:58:00 1988 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. Background: Ansii C introduced the concept of pre-processing numbers, I quote from the standard: Preprocessing numbers Syntax pp-number: digit . digit pp-number digit pp-number nondigit pp-number e sign pp-number E sign pp-number . Description A preprocessing number begins with a digit optionally preceded by a period ( . ) and may be followed by letters, underscores, digits, periods, and e+ , e- , E+ , or E- character sequences. Preprocessing number tokens lexically include all floating and integer constant tokens. Semantics A preprocessing number does not have type or a value; it must be converted (as part of phase 7) to a floating constant token or an integer constant token to acquire both. 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. 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'. 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. The best thing to do is get lots of complaints about this in to the committee during this next review period. I am willing to put up with pre-processing numbers, but they really need to be changed to separate ones that lead off with 0x from the others. I still like the longest valid prefix rule much better, but I can live with anything that does not turn perfectly valid C code into a lexical error. If anyone out there can find some existing code that does this, that would be excellent support for the need to fix this major flaw. ===================================================================== usenet: tahorsley@ssd.harris.com USMail: Tom Horsley compuserve: 76505,364 511 Kingbird Circle genie: T.HORSLEY Delray Beach, FL 33444 ====================== Astrology: Just say no! ======================