Path: csiph.com!eternal-september.org!feeder.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Keith Thompson <kst-u@mib.org>
Newsgroups: comp.lang.c
Subject: Re: Octal
Date: Wed, 28 Dec 2016 10:04:20 -0800
Organization: None to speak of
Lines: 47
Message-ID: <lnshp83p7f.fsf@kst-u.example.com>
References: <o3tsi4$es8$1@dont-email.me> <9f751874-98cf-4208-b809-9e6424600ac6@googlegroups.com> <o3tvf6$orj$1@dont-email.me> <e973caed-1397-4811-ad57-242b672edcd8@googlegroups.com> <o3u0t8$udg$1@dont-email.me> <5de6cdd0-6a36-40da-9bd6-4387d43c7947@googlegroups.com> <o3u4h0$c7m$1@dont-email.me> <9cb7833a-8479-4e61-8398-690783c4d975@googlegroups.com> <o3u96r$t9f$1@dont-email.me> <lnmvfh6s9t.fsf@kst-u.example.com> <o3uqga$1g2$1@dont-email.me> <ln37h87udw.fsf@kst-u.example.com> <o3v2hu$qq5$1@dont-email.me> <lntw9o6cr1.fsf@kst-u.example.com> <o407g6$dgp$1@dont-email.me> <a1f82620-a8cb-472f-b9e1-3b480f084587@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="U2FsdGVkX19xQ0TW7jMynF+NMvkwsOJl"
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux)
Cancel-Lock: sha1:tajMv+6XxbM8+vsxAad2XpSBCLo= sha1:2Ke+dYZHRmMpf4O0rl4H2ZezSrY=
Xref: csiph.com comp.lang.c:100449

supercat@casperkitty.com writes:
> 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.
>
> 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;".

And the standard made the behavior consistent.

When I fix your typo, changing plus() to plusplus(), the output of
"gcc -E" includes

      return i+ ++j;

The preprocessor inserts a space so that the "+" and "++" will be parsed
as distinct tokens.

I believe the description of the preprocessing phases is specifically
designed to permit a conforming compiler to use text as the output of
the preprocessor.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
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"