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 18:41:23 -0800 Organization: None to speak of Lines: 94 Message-ID: References: <9f751874-98cf-4208-b809-9e6424600ac6@googlegroups.com> <5de6cdd0-6a36-40da-9bd6-4387d43c7947@googlegroups.com> <9cb7833a-8479-4e61-8398-690783c4d975@googlegroups.com> <20280aee-5f78-47fa-ae22-c7bc852e3efb@googlegroups.com> <26119487-8644-4352-82bc-f1f1b6d7bb30@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="U2FsdGVkX188CxUhN40ZzQ0bA8vg5qzy" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) Cancel-Lock: sha1:i9zRcx/K2UToJALBndcx0OOrfrI= sha1:RIZtFXbbNN2FS0pllXcFiQefc3k= Xref: csiph.com comp.lang.c:100391 supercat@casperkitty.com writes: > On Tuesday, December 27, 2016 at 6:38:43 PM UTC-6, Keith Thompson wrote: >> supercat writes: >> > Is there some reason you think compiler writers would want to stick with >> > extra complexity whose primary purpose is to produce syntax errors from code >> > which would otherwise be unambiguous, rather than remove the weird cases >> > from their scanner and replace them with something simpler? >> >> What "extra complexity"? Have you read section 6.4.8 of the standard, >> describing preprocessing numbers? > > How many useful programs' behavior would be affected by a compiler which > did not start by grouping the pp-number terms as described but instead > either used a grammar that processed the different kinds of numeric literals > directly or else started by initially recognizing three kinds of chunks of > code: > > 1. Runs of whitespace. > 2. Runs of characters that are legal in identifiers, including digits > 3. Other characters, individually > > and then later worried about recognizing constructs like > > [1-9][0-9]* . [0-9*][eE] [+-] [0-9][0-9]* > > as floating-point literals?? Wow, that was all one run-on question. Next time, consider answering my questions before asking your own. Your "three kinds of chunks" approach would break 1.2e+3 (which currently is a single pp-number) into 5 pp-tokens: 1 (category 2) . (category 3) e (category 2) + (category 3) 3 (category 2) I suppose they'd all be merged into a single token in translation phase 7. Which means, among other things, that the current rule (each pp-token is converted to a single token) goes out the window, *and* whitespace remains significant longer that it currently does. I think that's a non-starter. The idea of replacing pp-numbers by, say, pp-integer-constants and pp-floating-constants, with a more restrictive syntax, might actually be workable -- or perhaps I just haven't spent enough time thinking about it to see any problems. And if I were designing the language from scratch today, perhaps that's the way I'd go. But it's still a substantial change, requiring a non-trivial amount of work to describe it in standardese, verify that there are no unexpected consequences, and implement it in every conforming C compiler. Is there a benefit to all this work other than being able to write 0x1E+1 rather than 0x1E + 1? > Would anything else render the as-if rule > inapplicable as justification for such a parsing approach if a compiler > had special logic to diagnose constructs where a + or - was preceded by an > alphanumeric run that ended with E but contained other non-numeric > characters? Perhaps that would make sense if I knew what you meant by the "as-if" rule. It seems to be something other than the usual meaning. (The standard doesn't mention the as-if rule other than in an index entry pointing to 5.1.2.3.) >> Again, suppose such a change is made. How long do you think it would >> take before C programmers can reliably assume that 0x1E+1 will *always* >> be treated as 3 tokens? > > Probably not terribly long, in many venues. Many compilers accept the > notation without complaint because it's trivially easy to do so. I am > not sure if it's possible to write a strictly-conforming program whose > behavior would be affected by the change, and I doubt such a change would > affect the behavior of any useful program which was not deliberately > contrived to be affected by it. If none of a compiler writers' customers > ever complain about the lack of a feature, the compiler writer would not > need to waste time worrying about it; if a compiler writers' customers > complain about the lack of a feature, such complaints would suggest that > people found it useful. "... in many venues". That's nice. I work with some rather old toolchains that aren't likely to be updated any time soon. The current definition is odd, but consistent, and it very rarely causes any problems. -- 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"