Re: preprocessor/9764: Varargs macro extension incorrectly expands if the varargs argument is the macro itself

Re: preprocessor/9764: Varargs macro extension incorrectly expands if the varargs argument is the macro itself

[neil]

Synopsis: Varargs macro extension incorrectly expands if the varargs argument is the macro itself

State-Changed-From-To: open->closed
State-Changed-By: neil
State-Changed-When: Wed Feb 19 23:48:50 2003
State-Changed-Why:
    3.1 and later give the following, which is correct.  I've not checked 3.0, but I expect it's similar.
    
    $ cat /tmp/bar.c
    #define func(a, varargs...) _func(a, ##b)
    
    func(a, func(a, b));
    $ gcc -E /tmp/bar.c
    # 1 "/tmp/bar.c"
    # 1 "<built-in>"
    # 1 "<command line>"
    # 1 "/tmp/bar.c"
    
    
    /tmp/bar.c:3:19: pasting "," and "b" does not give a valid preprocessing token
    _func(a,b);

http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=9764

Re: preprocessor/9764: Varargs macro extension incorrectly expands if the varargs argument is the macro itself

[Neil Booth]

The following reply was made to PR preprocessor/9764; it has been noted by GNATS.

From: Neil Booth <neil@daikokuya.co.uk>
To: Ryan Mallon <rpm31@student.canterbury.ac.nz>
Cc: gcc-gnats@gcc.gnu.org, gcc-bugs@gcc.gnu.org
Subject: Re: preprocessor/9764: Varargs macro extension incorrectly expands if the varargs argument is the macro itself
Date: Thu, 20 Feb 2003 06:49:17 +0000

 Ryan Mallon wrote:-
 
 > #define func(a, varargs...) _func(a, ##varargs)
 > 
 > The problems occurs when the macro name itself is used in the varargs 
 > part: e.g
 > 
 > func(a, func(b, c));
 > 
 > Incorrectly expands to:
 > 
 > _func(a, func(b, c));
 > 
 > Without the token paste opperator in the defintion it works as expected, 
 > but then I cannot have varargs=0. Im working with a large amount of 
 > existing code, so I cannot alter the actual calls on the macro definition.
 
 What makes you think it's incorrect?
 
 Neil.

Re: preprocessor/9764: Varargs macro extension incorrectly expands if the varargs argument is the macro itself

[Ryan Mallon]

The following reply was made to PR preprocessor/9764; it has been noted by GNATS.

From: Ryan Mallon <rpm31@student.canterbury.ac.nz>
To: neil@gcc.gnu.org, gcc-bugs@gcc.gnu.org, gcc-prs@gcc.gnu.org, nobody@gcc.gnu.org, gcc-gnats@gcc.gnu.org
Cc:  
Subject: Re: preprocessor/9764: Varargs macro extension incorrectly expands if the varargs argument is the macro itself
Date: Thu, 20 Feb 2003 13:04:50 +1300

 neil@gcc.gnu.org wrote:
 
 >Synopsis: Varargs macro extension incorrectly expands if the varargs argument is the macro itself
 >
 >State-Changed-From-To: open->closed
 >State-Changed-By: neil
 >State-Changed-When: Wed Feb 19 23:48:50 2003
 >State-Changed-Why:
 >    3.1 and later give the following, which is correct.  I've not checked 3.0, but I expect it's similar.
 >    
 >    $ cat /tmp/bar.c
 >    #define func(a, varargs...) _func(a, ##b)
 >
 Opps, I dont know how I missed that. The above line is incorrect, it 
 should read:
 
 #define func(a, varargs...) _func(a, ##varargs)
 
 Which is valid and allows the following uses:
 
 func(a);
 func(a, b);
 func(a, b, c);
 
 Which preprocess correctly to:
 
 _func(a);
 _func(a, b);
 _func(a, b, c);
 
 The problems occurs when the macro name itself is used in the varargs 
 part: e.g
 
 func(a, func(b, c));
 
 Incorrectly expands to:
 
 _func(a, func(b, c));
 
 Without the token paste opperator in the defintion it works as expected, 
 but then I cannot have varargs=0. Im working with a large amount of 
 existing code, so I cannot alter the actual calls on the macro definition.
 
 Sorry for the inconvience,
 Ryan Mallon
 
 

preprocessor/9764: Varargs macro extension incorrectly expands if the varargs argument is the macro itself

[rpm31]

>Number:         9764
>Category:       preprocessor
>Synopsis:       Varargs macro extension incorrectly expands if the varargs argument is the macro itself
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    unassigned
>State:          open
>Class:          wrong-code
>Submitter-Id:   net
>Arrival-Date:   Wed Feb 19 22:15:59 UTC 2003
>Closed-Date:
>Last-Modified:
>Originator:     rpm31@student.canterbury.ac.nz
>Release:        gcc version 2.95.2 19991024 (release)
>Organization:
>Environment:
SunOS 5.9 Generic sun4u sparc

Reading specs from /usr/local/gnu/pkg/gcc/2.95.2/lib/gcc-lib/sparc-sun-solaris2.7/2.95.2/specs
gcc version 2.95.2 19991024 (release)
 /usr/local/gnu/pkg/gcc/2.95.2/lib/gcc-lib/sparc-sun-solaris2.7/2.95.2/cpp -lang-c -v -Dsparc -Dsun -Dunix -D__svr4__ -D__SVR4 -D__sparc__ -D__sun__ -D__unix__ -D__svr4__ -D__SVR4 -D__sparc -D__sun -D__unix -Asystem(unix) -Asystem(svr4) -D__GCC_NEW_VARARGS__ -Acpu(sparc) -Amachine(sparc) -
GNU CPP version 2.95.2 19991024 (release) (sparc)
#include "..." search starts here:
#include <...> search starts here:
 /usr/local/gnu/pkg/gcc/2.95.2/include
 /usr/local/gnu/pkg/gcc/2.95.2/lib/gcc-lib/sparc-sun-solaris2.7/2.95.2/../../../../sparc-sun-solaris2.7/include
 /usr/local/gnu/pkg/gcc/2.95.2/lib/gcc-lib/sparc-sun-solaris2.7/2.95.2/include
 /usr/include
End of search list.
The following default directories have been omitted from the search path:
 /usr/local/gnu/pkg/gcc/2.95.2/lib/gcc-lib/sparc-sun-solaris2.7/2.95.2/../../../../include/g++-3
End of omitted list.
>Description:
When using the varargs macro extension, the preprocessor incorrectly expands the macro if one of the variable arguments is the macro name itself. The problem does not occur if the macro name is used as one of the other arguments or if another macro definition is used as one of the varargs arguments. The problem does not occur if the token paste (for allowing no variable arguments) is ommitted.
>How-To-Repeat:
<code>
#define func(a, varargs...) _func(a, ##b)

func(a, func(a, b));
</code>

Expands as: _func(a, func(a, b))
>Fix:
Workaround hacks include using two macros (one for the call and one for the argument), removing the token paste operator (this reduces flexibility however) and preprocessing twice (yuck).
>Release-Note:
>Audit-Trail:
>Unformatted: