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 10:19:59 -0800 Organization: None to speak of Lines: 64 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="8756"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+GjJkka/G/MMuiwMSrd6Rf" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) Cancel-Lock: sha1:YW9MPi0uPcmU9fSM/En8PwPJWnc= sha1:8MZiWW0Mg0jzolYFgV/5+huDe/E= Xref: csiph.com comp.lang.c:100455 BartC writes: > On 28/12/2016 16:17, supercat@casperkitty.com wrote: >> On Wednesday, December 28, 2016 at 5:27:34 AM UTC-6, Bart wrote: >>> This is contrary to my understanding of how the preprocessor works, >>> which is that the output is considered to be text-based, not >>> token-based, and the next compilation phase will see the character >>> sequence "127.0.0.1" and re-tokenise it whichever way it wants. >> >> Prior to the C Standard, some compilers had a preprocessor stage which ran >> through all the source files and combined them into a preprocessor-output >> text file, which was then fed to subsequent compilation stages, while others >> would have the preprocessor generate data in an internal-use format (either >> in memory or disk) which retained the results of scanning certain parts. > > I rarely use macros with parameters but never realised they were such a > minefield. And in fact the rules would effect also affect straight > source whether it uses macros or not. They're not really that much of a minefield. >> For example, given something like: >> >> #define plusplus() ++ >> int main(void) >> { >> int i=0,=0; >> return i+plus()j; >> } >> >> some compilers which ran the preprocessor as a separate stage may have >> converted the return statement into "return i+++j;" which would in turn >> be parsed as "return i++ +j;", but others may have converted the first >> + to a token before expanding the macro "plus()", and thus interpreting >> the statement as "return i+ ++j;". > > How was it possible to have a language that gave different results > depending on how the preprocessing rules were interpreted? It was possible because the language had not yet been standardized. Since 1989, it has been, and there is no ambiguity in supercat's example. `i+plus()j` is unambiguously equivalent to `i + ++ j`. > But fortunately your example is parsed as "+ ++" on all the compilers > I've tried. Good. > (Tomorrow I'll have a go at writing a preprocessor to see how far I can > get; not an enticing prospect. Hopefully it'll have little impact on > throughput for code that sparsely uses macros (currently around 5Mlps). > > But there is no way my pp would generate "+++" and then "++","+" from > that example, no matter what the Standard says! Nor "0x123E+3" as a > single token.) So you're going to implement a C preprocessor, but you're not interested in what the Standard says. Interesting choice. -- 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"