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 16:46:35 -0800 Organization: None to speak of Lines: 52 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="U2FsdGVkX1/KEFaxeaUAvpGCCCLNsj9a" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) Cancel-Lock: sha1:m+35oE8r1HVYLA1pabbXjNLJ64E= sha1:QIiauHbkZ+TKNVzCZq7E9IerewA= Xref: csiph.com comp.lang.c:100381 BartC writes: > 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. 0x123E+3 is illegal because it's a valid preprocessing number that is not a valid integer or floating constant. > Now I can see that it should be parsed as 0x123E followed by +3. How did you reach that conclusion? A preprocessing number is never split into multiple tokens. It's similar to the "maximal munch" rule, which says that a+++++b is equivalent to a ++ ++ + b, which is a syntax error, even though a++ + ++b would be legal. > But some compilers do that (lccwin and DMC), and some don't. > > While some reject 0x123E+3 in a preprocessing expression. > > (I think when C compilers can't agree between themselves, then I > shouldn't worry about it either!) Whether you worry about it is up to you. But I believe that compilers that don't diagnose 0x123E+3 as a syntax error are non-conforming. I'm not very surprised that some compilers mishandle this, but if they don't handle preprocessing numbers correctly I'm a bit concerned about related bugs. -- 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"