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

Groups > comp.lang.c > #146720

Re: Preprocessor and "empty" substitutions

Show all headers | View raw

Andrey Tarasevich <andreytarasevich@hotmail.com> writes:

> On 10/7/2019 1:05 PM, Ben Bacarisse wrote:
>>
>> <EMPTY> is seen as an object-like macro and is replaced by nothing, but
>> the scan does not go back to see if this makes any difference to the
>> decision not to recognise an invocation of a function-like macro.  No
>> further tokens can be replaced and, importantly, the resulting list:
>>
>>    <OUTPUT> <(> <i> <)>
>>    is /not/ scanned again.
>>
>
> Interesting. Well, if we try something like
>
>     #define A x
>     #define B A
>     #define C B
>     #define D C
>
>     int main(void)
>     {
>       int D = 42;
>       printf("%d\n", x); // outputs '42'
>     }
>
> 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.

The reason I don't like using "repetitive" or "recursive" in this
context is that C's macros famously can't "loop" or "recurse" in the
conventional sense, as is permitted in many other macro processors.

> Once 'D' is replaced with 'C', the result _is_ rescanned again, which
> leads to 'C's being replaced with 'B' and so on until it reaches 'x'.

Yes.  Your stress on "_is_" suggests you thought I was saying something
that contradicts this.  I did not intend to, though I did skip a step,
because when EMPTY is replaced by nothing, that empty replacement list
is (logically) scanned for more macros.

> 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.

The "re" in rescanned is maybe a bit odd because there has been (as far
as I can see) no previous scan of that list.  I would just have said
that "the replacement list is then scanned for more macro names".

I think if your first thought were the intended meaning, it would have
to be stated very clearly that the scan was not of this macro's
replacement but of the whole replacement list of the outermost expansion
(if there is one).

> But apparently it is not the case: it refers to the just-substituted
> replacement list. I.e. the [recursive] rescan is done locally.

I'm not keen on that way of describing it but if it works for you,
that's fine.

-- 
Ben.

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