Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!feeder.erje.net!1.eu.feeder.erje.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: Thu, 29 Dec 2016 15:33:38 -0800 Organization: None to speak of Lines: 83 Message-ID: References: <5de6cdd0-6a36-40da-9bd6-4387d43c7947@googlegroups.com> <9cb7833a-8479-4e61-8398-690783c4d975@googlegroups.com> <2v666c9vvvlienafoqpqdk32m56fpv6tph@4ax.com> <2e01e7a5-2ba6-412b-8e38-25f25d3f53cd@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: mx02.eternal-september.org; posting-host="9cde9db04945311bb4638cac08ff52e5"; logging-data="22731"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18YBnwzCy8quiHsWyWtw8Pu" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) Cancel-Lock: sha1:OpB1U2aa5bm8vRq2gxVJf4lxuyk= sha1:AsFAyMffNfF9yG8MwIW/Lb5RqbY= Xref: csiph.com comp.lang.c:100568 supercat@casperkitty.com writes: > On Thursday, December 29, 2016 at 3:35:25 PM UTC-6, Tim Rentsch wrote: >> supercat writes: >> > The only thing that erroneously regards 0x123E+4 as a combination of >> > floating and integer constants is a sloppily-written standard. [...] >> >> Ahh, good old supercat.. never one to let facts stand in the way >> of an unwarranted accusation. > > The rationale for the Standard recognizes that the grammar as written will > reject constructs like 0x1E+2, and offers no real justification beyond the > fact that the authors are worried that a rule which didn't reject such > constructs might pose an undue burden on the preprossor (notwithstanding > the fact that many compilers seemed to have no trouble recognizing that > 0x1E+2 was an expression that added the hex constant 0x1E and the number 2). The rationale also mentions simplifying the description of preprocessing. Compilers that "have no trouble recognizing" it are non-conforming. I wonder what other language rules they're ignoring. > The situation with x+++++y is not comparable, because having that scan as > x++ + ++y would require feedback from the parsing stage to the scanning > stage--something not required to recognize that a token starting with 0x > is a hex literal and cannot contain a "+" sign. Further, the rule which > eagerly left-binds the "++" operator is necessary to prevent "x++ +y" from > parsing as the equally-valid "x + + + y". And scanning 0x1E+2 as 0x1E + 2 would, given the current definition of a pp-number, require feedback from translation phase 7 to translation phase 3. > Can you provide examples of plausibly-useful C89 programming construct whose > behavior would be affected by changing the scanning rules so that: > > 1. The ## operator will act as though the left and right sides are run > together with no whitespace, even if that would not cause any new token > to bridge the gap between them. > > 2. After # directives are processed, tokens are initially broken up as > strings of [0-9A-Za-z_] separated by strings of other characters; all > other scanning is deferred until after macro substitution. The point of this, I think, is to allow multiple preprocessing tokens to be stitched together into a single token; is that correct? I think that's a really bad idea that would unnecessarily complicate the description of how C source is processed. Translating one pp-token to one token is a much simpler rule that makes it easier to reason about C code. > The addition of hex floating-point literals would make it necessary to add > an extra rule to avoid having the preprocessor perform macro substitution > on the second half of the literal 0x1.ABC, 0x1.ABC is not a valid floating constant, but that would apply to `0x1.ABCp2`. I wonder how many other additional rules would be needed to make your scheme work. > but other than that can you offer > any examples of conveivably-useful constructs where the above rules would > not yield behavior equivalent to the Standard? Not off the top of my head (and I'm not willing to spend much time thinking of any such examples). If allowing 0x1E+2 is that important to you (I can't imagine why), I think you could "fix" it by dropping the idea of pp-numbers and requiring the preprocessor to recognize integer and floating constants using the same syntax as 6.4.4.1 and 6.4.4.2. Then 0x1E+2 would be three preprocessing tokens (integer constant 0x1E, punctuator +, and integer constant 2), each of which would be converted to a single token. I do not advocate such a change, but I suppose I wouldn't object to it. On the other hand, there could still be problems I'm not seeing. In any case, I'm perfectly happy with the status quo, though it is mildly interesting to see that it causes this trivial issue in an obscure corner case. -- 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"