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: Wed, 28 Dec 2016 09:41:28 -0800 Organization: None to speak of Lines: 56 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> <87tw9ogt3s.fsf@bsb.me.uk> <87inq4ggus.fsf@bsb.me.uk> <390aaa5f-d06a-4b89-b79c-98ca28b8208a@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: mx02.eternal-september.org; posting-host="eac9cc7ad54a0b680082b6004da4ef88"; logging-data="8756"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19q7yCnT5QVgYkFilKstPYa" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) Cancel-Lock: sha1:u226Mwdxfpm0n11BHja1eJiyN9w= sha1:DBGcZS6BYlNuYRtzs5LOlNkBLOE= Xref: csiph.com comp.lang.c:100446 supercat@casperkitty.com writes: > On Wednesday, December 28, 2016 at 10:26:28 AM UTC-6, Ben Bacarisse wrote: >> BartC writes: >> > The sounds more like a bug in the language definition. >> >> I agree that that point could be debated (not that I want to debate it). >> I hope that you agree that what "users might reasonably expect" will, on >> many occasions, include what the language definition says they can >> expect. > > On many occasions it will. On the other hand, a supposed intention of > the C Standard was to describe a language consistent with the way existing > compilers behaved. If a sloppily-written part of the Standard describes > rules which make the language less useful and doesn't coincide with how > existing compilers behave, and if there is no stated rationale for making > compilers change behavior to match the Standard, which should be presumed > defective--the Standard, or compilers which continue to behave in a manner > more useful than what the Standard would prescribe? You seem to be making an assertion about how pre-ANSI compilers handled things like 0x123e+3. Would you care to be more specific? I do not believe that part of the standard is sloppily written. I believe it was written carefully and deliberately, with an understanding of the tradeoffs. The behavior it requires is admittedly odd in some rare corner cases, but it is consistent, and it lets us determine the legality and meaning of anything that looks like a constant. As it turns out, the ANSI C Rationale actually discusses the thought that went into the definition of pp-numbers -- using an example almost identical to the one we've been arguing about. https://www.lysator.liu.se/c/rat/c1.html#3-1-8 The notion of preprocessing numbers has been introduced to simplify the description of preprocessing. It provides a means of talking about the tokenization of strings that look like numbers, or initial substrings of numbers, prior to their semantic interpretation. In the interests of keeping the description simple, occasional spurious forms are scanned as preprocessing numbers --- 0x123E+1 is a single token under the rules. The Committee felt that it was better to tolerate such anomalies than burden the preprocessor with a more exact, and exacting, lexical specification. It felt that this anomaly was no worse than the principle under which the characters a+++++b are tokenized as a ++ ++ + b (an invalid expression), even though the tokenization a ++ + ++ b would yield a syntactically correct expression. In both cases, exercise of reasonable precaution in coding style avoids surprises. -- 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"