Nested macro expansion - comp.std.c

This is a Usenet group - learn more

View this group in the new Google Groups

Message from discussion Nested macro expansion

Jun Woong

View profile

More options Jul 15 2003, 9:59 pm

Newsgroups: comp.std.c

From: "Jun Woong" <mycob...@hanmail.net>

Date: Wed, 16 Jul 2003 10:59:20 +0900

Local: Tues, Jul 15 2003 9:59 pm

Subject: Re: Nested macro expansion

Print | View thread | Show original | Report this message | Find messages by this author

"Paul Mensonides" <leavi...@comcast.net> wrote in message news:dD%Qa.60207$sY2.28289@rwcrnsc51.ops.asp.att.net...
> Jun Woong wrote:

> > Now, it's not clear that n(m) should be considered to be a recursive
> > expansion of m; for more details, please see DR017Q19, Q23 and

> The non-normative reference is incorrect. The behavior is specified, it just
> isn't very clear. The secondary indirect macro expansion should expand because
> the macro name is not found during the rescanning and further replacement of the
> replacement list. This is somewhat hidden though. A function-like macro is not
> invoked unless it is trailed by a left parenthesis. This causes the the
> replacement list rescan to be complete prior to the invocation of the tail
> macro:

> #define A() B
> #define B() A

> A() // B
> A()() // A
> A()()() // B
> // etc.

Then, could you show me a more reliable non-normative reference like
the committee's answer to another DR or the committee minutes, not
you own interpretation? Because what I cited were the authoritative
interpretations which the committee formed for C90, and C99 still has
the following non-normative wording (even if Doug said differently in
the discussion cited in my previous posting, which was the reason I
mentioned it),

J.1 (Unspecified behavior)

When a fully expanded macro replacement list contains a function-
like macro name as its last preprocessing token and the next
preprocessing token from the source file is a (, and the fully
expanded replacement of that macro ends with the name of the first
macro and the next preprocessing token from the source file is
again a (, whether that is considered a nested replacement.

I need an interpretation which has an equivalent authoritative to
overthrow these.

> However, if the opening parethesis of the invocation *is* found during the
> rescan, the macro is considered invoked,

#define a()

According to the literal reading of the standard (and your
interpretation) this macro "a" is considered invoked but never
terminated, since there is no closing parenthesis. Is this code
invalid? I think that this means an implementation is required to
recognize the corresponding closing parenthesis to decide expasion for
the invoked macro.

> and therefore it is a recursive
> invocation attempt:

> #define A() B(
> #define B() A

> A() ) () // A()

My understanding was that this is not different from your first
example above, even if the committee mentioned nothing direct about
this. The invocation is completed with tokens from the remaining
source file, and in the Rationale (for both C90 and C99) the committee
provides a rationale to leave it as unspecified:

However, given the definitions

#define f(a) a*g
#define g(a) f(a)

the expansion will to be either 2*f(9) or 2*9*g: there are no
clear grounds for making a decision whether the f(9) token string
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
resulting from the initial expansion of f and the examination of
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
the rest of the source file should be considered as nested within
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
the expansion of f or not.
~~~~~~~~~~~~~~~~~~~~~~~~~

which can apply to your second example, too.

--
Jun, Woong (mycob...@hanmail.net)
Dept. of Physics, Univ. of Seoul

Create a group - Google Groups - Google Home - Terms of Service - Privacy Policy

Account Options