[Bug preprocessor/35301] New: Function macro nesting depth appears to be uncomfortably limited.

[Bug preprocessor/35301] New: Function macro nesting depth appears to be uncomfortably limited.

[_deepfire at feelingofgreen dot ru]

It appears that CPP decides to stop expansion at some point.

Re-feeding the output to cpp iteratively peels macro levels.

#include <stdlib.h>
#include <stdio.h>

#define _(op, ...) op(__VA_ARGS__)
#define _if(expr, then, els) if (expr) { then; } else { els; }
#define progn(...) ({__VA_ARGS__;})
#define when(expr, ...) _(_if, expr, \
                          _(progn, ## __VA_ARGS__), )
#define unless(expr, ...) _(_if, !(expr), \
                                 _(progn, ## __VA_ARGS__), )
#define warn(format, ...) _(fprintf, stderr, format "\n", ## __VA_ARGS__)
#define when_warn(expr, tail, format, ...) _(when, expr, \
                                              _(warn, format, ## __VA_ARGS__),
\
                                              tail)
#define exssert_with_epilogue_nexpr(expr, epilogue, format, ...) _(when_warn,
expr, _(exit, 1), format, ## __VA_ARGS__)
#define exssert_nexpr(expr, format, ...) _(exssert_with_epilogue_nexpr, expr,
(), format, ## __VA_ARGS__)
#define xmallocq(size) _(progn,                                         \
                          void *gensym = malloc(size);                  \
                          _(exssert_nexpr, gensym == NULL,             \
                             "malloc returned NULL at: %s:%s, line %d",
__FILE__, __FUNCTION__, __LINE__); gensym)

int main()
{
        xmallocq(2000000000);
        exit(0);
}

==>

int main()
{
        ({void *gensym = malloc(2000000000); _(exssert_with_epilogue_nexpr,
gensym == ((void *)0), (), "malloc returned NULL at: %s:%s, line %d","<stdin>",
__FUNCTION__, 88); gensym;});
 exit(0);
}


-- 
           Summary: Function macro nesting depth appears to be uncomfortably
                    limited.
           Product: gcc
           Version: 4.3.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: preprocessor
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: _deepfire at feelingofgreen dot ru
 GCC build triplet: x86_64-linux-gnu
  GCC host triplet: x86_64-linux-gnu
GCC target triplet: x86_64-linux-gnu


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35301

[Bug preprocessor/35301] Function macro nesting depth appears to be uncomfortably limited.

[pinskia at gcc dot gnu dot org]

------- Comment #1 from pinskia at gcc dot gnu dot org  2008-02-23 03:45 -------
I think this is correct CPP behavior.
it only evaluates one level of _ .

Think of:
#define a b
#define b a
b
a

What does that do?
it just does:
b
a

Instead of causing an infinite loop.

Once we try to revaluate _ again after evaluating it once from the macro
expansion, CPP no longer evaluates it again.
So the first time we expand xmallocq, we get _( progn ... , _(exssert_nexpr,
...) ) and then
we expand the two _(, we get:
progn(..., exssert_nexpr(...) ) and new expands progn and exssert_nexpr, we
get:

        ({void *gensym = malloc(2000000000); _(exssert_with_epilogue_nexpr,
gensym == ((void *)0), (), "malloc returned NULL at: %s:%s, line %d","t.c",
__FUNCTION__, 27); gensym;});


And then since we already used _(x, ...), CPP can no longer expand anything so
it stops.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35301

[Bug preprocessor/35301] Function macro nesting depth appears to be uncomfortably limited.

[_deepfire at feelingofgreen dot ru]

------- Comment #2 from _deepfire at feelingofgreen dot ru  2008-02-23 11:56 -------
> I think this is correct CPP behavior.
> it only evaluates one level of _ .

Interesting, reading the CPP manual[1] gives me an impression that there is
at least intent to support nested expansions:

> You might wonder, “Why mention the prescan, if it makes no difference? And why not skip it and make the preprocessor faster?” The answer is that the prescan does make a difference in three special cases:
>
>    * Nested calls to a macro.
>
>      We say that nested calls to a macro occur when a macro's argument contains a call to that very macro. For example, if f is a macro that expects one argument, f (f (1)) is a nested pair of calls to f. The desired expansion is  made by expanding f (1) and substituting that into the definition of f. The prescan causes the expected result to happen. Without the prescan, f (1) itself  would be substituted as an argument, and the inner use of f would appear during the main scan as an indirect self-reference and would not be expanded. 

But in my case the nesting is not immediately observable, and therefore
requires further body expansion to detect and apply that strategy.

I wonder what will be the final call of GCC people on that -- will this
use pattern be considered legit-enough to deserve support, or not.

1. http://gcc.gnu.org/onlinedocs/cpp/Argument-Prescan.html#Argument-Prescan


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35301

[Bug preprocessor/35301] Function macro nesting depth appears to be uncomfortably limited.

[joseph at codesourcery dot com]

------- Comment #3 from joseph at codesourcery dot com  2008-02-23 13:47 -------
Subject: Re:  Function macro nesting depth appears
 to be uncomfortably limited.

I think GCC aims to implement the version of the rescanning rules 
described in X3J11/86-196, as posted in Dave Prosser's message included in 
bug 1565.  (This specifies some details the C standard leaves 
underspecified.)


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35301

[Bug preprocessor/35301] Function macro nesting depth appears to be uncomfortably limited.

[neil at gcc dot gnu dot org]

------- Comment #4 from neil at gcc dot gnu dot org  2008-02-23 14:03 -------
To be honest this isn't even a disputed case from what I can see.  I doubt you
can find a serious C implementation (i.e. tcc etc. doesn't count) that will do
what you expect.


-- 

neil at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |INVALID


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35301