[Bug preprocessor/58887] New: Allow recursion in varadic macros?

["mtewoodbury at gmail dot com" <gcc-bugzilla at gcc dot gnu dot org>]

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

            Bug ID: 58887
           Summary: Allow recursion in varadic macros?
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: enhancement
          Priority: P3
         Component: preprocessor
          Assignee: unassigned at gcc dot gnu.org
          Reporter: mtewoodbury at gmail dot com

With good reason, recursion in macro definitions is suppressed -- it leads to
infinite expansion loops and subsequent software failure, HOWEVER

Recursion of varadic macros where the number of arguments in the argument list
decreases would necessarily stop expanding when the argument list became empty.

It would be nice if this could be handled easily, but doing it requires an
extension -- something beyond what the standard calls for/allows.

I can see two ways to do this -- there may be other ways as well:

1)  Allow recursion as long as the new invocation has fewer arguments
    than the current invocation.

    This is the general solution, but should only be allowed if some
    special mode is set, such as a command line switch or 'pragma'

2)  Make the number of arguments easily available.

    There is a way to write a varadic macro that return a count of
    its arguments, but it has severe limitations -- it will necessarily
    have an upper bound on the number of arguments it can count and
    that limit will be half the implementation limit the preprocessor
    puts on the number of arguments that can be passed to varadic
    macros.

    It would help if there were a predefined macro that did this
    counting and did not have the upper bound limitation.

    Once the argument count is available, it is possible to construct
    the name of a macro for the correct number of arguments and have
    those macros chain their expansion.

    This solution is sub-optimal:  macros for each argument count have
    to be defined, which means there will be an arbitrary upper bound
    on the number of arguments handled and puts a strain on preprocessor
    resources.

    For this reason, solution 1 is preferable.