This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
Re: preprocessor/9764: Varargs macro extension incorrectly expands if the varargs argument is the macro itself
- From: Ryan Mallon <rpm31 at student dot canterbury dot ac dot nz>
- To: neil at gcc dot gnu dot org, gcc-bugs at gcc dot gnu dot org, gcc-prs at gcc dot gnu dot org, nobody at gcc dot gnu dot org, gcc-gnats at gcc dot gnu dot org
- Date: Thu, 20 Feb 2003 13:04:50 +1300
- Subject: Re: preprocessor/9764: Varargs macro extension incorrectly expands if the varargs argument is the macro itself
- References: <20030219234850.5116.qmail@sources.redhat.com>
neil at gcc dot gnu dot 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