Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.c > #146767

Re: Preprocessor and "empty" substitutions

From Andrey Tarasevich <andreytarasevich@hotmail.com>
Newsgroups comp.lang.c
Subject Re: Preprocessor and "empty" substitutions
Date 2019-10-08 11:41 -0700
Organization A noiseless patient Spider
Message-ID <qnil93$g3e$1@dont-email.me> (permalink)
References <qng257$6ts$1@dont-email.me> <874l0kl3sm.fsf@bsb.me.uk> <qngdgq$g7u$1@dont-email.me> <87muecjcfo.fsf@bsb.me.uk>

Show all headers | View raw


On 10/7/2019 5:41 PM, Ben Bacarisse wrote:
>>
>> we'll see that the above occurrence of macro name 'D' is ultimately
>> replaced by 'x', meaning that there is some kind of
>> _repetitive/recursive_ rescan involved.
> 
> If that's how you like to think of it, then go for it.  I just say that
> when a macro is expanded, that expansion is scanned for more macros.

Well, the text of the standard seem to draw a pretty specific 
distinction between how parameter values are substituted and how nested 
macro invocations are substituted:

* In case of parameters it states that first of all, any macro 
substitutions inside the parameter value are processed. And only when 
this process is complete (i.e. everything is exhaustively substituted) 
the final result is planted into the parent macro.

* In case of nested macro invocations it is the other way around: the 
substitution list for the invoked macro is immediately planted into the 
parent macro, and only afterwards that planted list is rescanned for 
more macro invocations.

This appears to be done for some specific reason. And the first reason 
for that distinction that come to mind is that parameters are intended 
to be processed out-of-context, while macro invocations are intended to 
be handled (rescanned) in-context (in the context of surrounding tokens).

> 
>> I presume that what you mean is that the rescan process is done
>> _locally_.
> 
> Well, I meant what I said but it was obviously not clear.
> 
>> 6.10.3/9 (http://port70.net/~nsz/c/c11/n1570.html#6.10.3p9) says
>>
>>     "The replacement list is then rescanned for more macro names as
>>     specified below."
>>
>> I initially assumed that the term "replacement list" in this quote is
>> referring to the entire replacement list of the top-level macro.
> 
> To my mind, that would be an odd interpretation.  It seems obvious that
> "the replacement list" refers to the one in the definition being
> expanded.

May be. But in that case it is not clear why wouldn't they just unify 
the specification of macro parameter substitution with the specification 
of macro invocation: first, exhaustively substitute everything that can 
be substituted in the replacement list and only then plant the result 
into the target location.

-- 
Best regards,
Andrey Tarasevich

Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread


Thread

Preprocessor and "empty" substitutions Andrey Tarasevich <andreytarasevich@hotmail.com> - 2019-10-07 12:03 -0700
  Re: Preprocessor and "empty" substitutions Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-10-07 21:05 +0100
    Re: Preprocessor and "empty" substitutions Andrey Tarasevich <andreytarasevich@hotmail.com> - 2019-10-07 15:16 -0700
      Re: Preprocessor and "empty" substitutions Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-10-08 01:41 +0100
        Re: Preprocessor and "empty" substitutions Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-10-09 01:58 +0100
        Re: Preprocessor and "empty" substitutions Andrey Tarasevich <andreytarasevich@hotmail.com> - 2019-10-08 11:41 -0700
          Re: Preprocessor and "empty" substitutions Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-10-09 06:34 -0700

csiph-web