Path: csiph.com!eternal-september.org!feeder.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Keith Thompson Newsgroups: comp.lang.c Subject: Re: Octal Date: Tue, 27 Dec 2016 17:19:45 -0800 Organization: None to speak of Lines: 71 Message-ID: References: <9f751874-98cf-4208-b809-9e6424600ac6@googlegroups.com> <5de6cdd0-6a36-40da-9bd6-4387d43c7947@googlegroups.com> <9cb7833a-8479-4e61-8398-690783c4d975@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: mx02.eternal-september.org; posting-host="eac9cc7ad54a0b680082b6004da4ef88"; logging-data="22601"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19yTUsx+ttUru4Dk34FlPQP" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) Cancel-Lock: sha1:LQLuUmLuq4qNUmm6xZ2i1zWlQfI= sha1:bHHclpI5h6X+zhxrtc4241Bo+r8= Xref: csiph.com comp.lang.c:100386 Ian Collins writes: > On 12/28/16 12:09 PM, BartC wrote: >> On 27/12/2016 22:49, Ian Collins wrote: >>> On 12/28/16 11:39 AM, BartC wrote: >>>> On 27/12/2016 20:17, Keith Thompson wrote: >>>>> BartC writes: >>>>> [...] >>>>>> (But isn't 0x123E+3 illegal? I thought it had to be 0x123P+3, with the >>>>>> +3 now meaning a binary exponent.) >>>>> >>>>> Yes. >>>>> >>>>> The preprocessor treats 0x123E+3 as a single preprocessing number >>>>> (see N1570 6.4.8). Since it's neither a valid integer constant nor >>>>> a valid floating-point constant, it's treated as a syntax error in >>>>> translation phase 7. >>>>> >>>>> On the other hand, 0x123F+3 is treated by the preprocessor as three >>>>> tokens (because it uses F rather than E): the preprocessing number >>>>> 0x123f (which becomes an integer constant in phase 7), the symbol >>>>> "=", and the constant 3. >>>> >>>> I'm confused now. I thought 0x123E+3 was illegal because it looked like >>>> an attempt to write a floating point literal in hex, but hex uses 'E' >>>> for a digit. >>>> >>>> Now I can see that it should be parsed as 0x123E followed by +3. But >>>> some compilers do that (lccwin and DMC), and some don't. >> >>> Which ones? >> >> printf("%x\n",0x123E+3); >> >> Output >> >> Pelles C Compiler error >> lccwin 1241 >> Digital Mars 1241 >> gcc/TDM Compiler error >> Tiny C Compiler error >> MSVC 1241 > > > Compiler error or Compile error? I'm not sure what distinction you're making. Presumably it's a compile-time error message. For example, gcc and clang print: error: invalid suffix "+3" on integer constant and tcc prints: error: invalid number > Isn't 1241 an windows linker error? 0x1241 is the value of 0x123E + 3. (Using "0x%x" rather than "%x" would have made the output clearer.) Apparently those compilers (incorrectly, I believe) treat 0x123E+3 as a sequence of 3 tokens. N1570 5.1.1.2: In translation phase 3, the source file is decomposed into preprocessing tokens. In phase 7, "Each preprocessing token is converted into a token." Tokens and preprocessing tokens are defined in 6.4 (Lexical elements). A "pp-number", defined in 6.8.4, is a kind of preprocessing token, and a "constant" (which includes integer and floating constants) is a kind of token. Conclusion: 0x123E+3 is a single preprocessing token, and it cannot legally be converted into more than one token. Since it isn't a valid token, it's a syntax error. -- Keith Thompson (The_Other_Keith) kst-u@mib.org Working, but not speaking, for JetHead Development, Inc. "We must do something. This is something. Therefore, we must do this." -- Antony Jay and Jonathan Lynn, "Yes Minister"