Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!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: Wed, 28 Dec 2016 12:01:11 -0800 Organization: None to speak of Lines: 57 Message-ID: References: <9f751874-98cf-4208-b809-9e6424600ac6@googlegroups.com> <5de6cdd0-6a36-40da-9bd6-4387d43c7947@googlegroups.com> <9cb7833a-8479-4e61-8398-690783c4d975@googlegroups.com> <586387da.716953@news.xs4all.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: mx02.eternal-september.org; posting-host="eac9cc7ad54a0b680082b6004da4ef88"; logging-data="18198"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18OiwrguPJrAz0pKTKOcfFy" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) Cancel-Lock: sha1:X0A6JzsrFFLKEekZ5Xjarcsb9R4= sha1:zYIn/GyC5Cfp0wa4PWUG7x0uYtk= Xref: csiph.com comp.lang.c:100550 BartC writes: > On 28/12/2016 17:31, Keith Thompson wrote: >> BartC writes: >> [...] >>> But if a compiler is going to think up ways that a programmer may have >>> written numbers wrongly then what about: >>> >>> 0x123E3 >>> >>> Maybe /this/ should have been written as 0x123p3! >>> >>> Or 123E3, which was supposed to be 0x123E3 but the the "0x" was left >>> out. Or 0123E3, when the "x" is left out. >>> >>> Why is the compiler not giving errors in these cases? Surely they must >>> count as pp-numbers too. >> >> 0x123E3 is a perfectly valid hexadecimal integer constant. 123E3 is a >> perfectly valid floating constant. Yes, they're valid pp-numbers, and >> they're converted to valid constants in translation phase 7. That's why >> compilers don't print error messages for them -- because they're not >> errors. >> >> I've already explained why 0x123e+3 is a syntax error. I understand >> that you don't like that fact; I'm not entirely pleased about it myself. >> But it is what it is. > > David Brown suggested the compiler messages were given because 0x123E+3 > was ambiguous (possible user-error). In which case I gave other such > examples that don't generate an error. I think there may have been an ambiguous use of the word "ambiguous". As far as the C standard is concerned, 0x123E+3 is not ambiguous. It is a valid pp-number that cannot be converted to a valid constant, resulting in a syntax error. That's why it's diagnosed. The fact that it could be ambiguous *to a human reader* (the writer might have meant either `0x123E + 3` or `0x123p+3`) is an after-the-fact observation which suggests that treating it as a syntax error isn't such a bad thing. It is *not* the underlying rationale for the behavior, or is it an argument that all constructs that might be ambiguous to a human reader should be diagnosed. (I don't want a compiler warning me about `2+2` because I might have meant `2E+2`. Do you?) The underlying rationale has already been explained, and was stated by the committee in section 3.1.8 of the ANSI C rationale: https://www.lysator.liu.se/c/rat/c1.html#3-1-8 Just how freaking difficult is it to avoid writing 0x123E+3? -- 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"