RE: preprocessing question

["Dave Korn" <dave dot korn at artimi dot com>]

On 26 September 2006 08:43, Jan Beulich wrote:

>>>> Daniel Jacobowitz <drow@false.org> 25.09.06 18:43 >>>
>> On Mon, Sep 25, 2006 at 05:23:34PM +0200, Jan Beulich wrote:
>>> Can anyone set me strait on why, in the following code fragment
>>> 
>>> int x(unsigned);
>>> 
>>> struct alt_x {
>>> 	unsigned val;
>>> };
>>> 
>>> #define x        alt_x
>>> #define alt_x(p) x(p+1)
>>> 
>>> int test(struct x *p) {
>>> 	return x(p->val);
>>> }
>>> 
>>> the function invoked in test() is alt_x (rather than x)? I would have
>>> expected that the preprocessor
>>> - finds that x is an object like macro, and replaces it with alt_x
>>> - finds that alt_x is a function-like macro and replaces it with x(...)
>>> - finds that again x is an object like macro, but recognizes that it
>>> already participated in expansion, so doesn't replace x by alt_x a
>>> second time.

> While, as Andreas also pointed out, the standard is a little vague in
> some of what it tries to explain here, it is in my opinion clearly said
> that the re-scanning restrictions are bound to the macro name, not
> the fact that a function-like macro's expansion result is being
> re-scanned. Hence, the re-scanning process of x has to be
> considered still in progress while expanding alt_x, and consequently
> x should not be subject to expansion anymore.

  Actually, it's because cpp has a special exception for recursive macros,
isn't it?  After

>>> #define x        alt_x

the preprocessor token "x" is an object-like macro standing for "alt_x", so
when we get to

>>> #define alt_x(p) x(p+1)

  what the preprocessor sees after the first round of expansion is

#define alt_x(p) alt_x(p+1)

  at which point cpp's "No recursive expansion" rule kicks in and all further
expansion stops.

"     If the expansion of a macro contains its own name, either directly or
via intermediate macros, it is not expanded again when the expansion is
examined for more macros.  This prevents infinite recursion.  *Note
Self-Referential Macros::, for the precise details.  "


    cheers,
      DaveK
-- 
Can't think of a witty .sigline today....