This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
Re: Serious error-causing change in new CPP's -traditional behavior
- To: rearnsha at arm dot com
- Subject: Re: Serious error-causing change in new CPP's -traditional behavior
- From: Dave Brolley <brolley at redhat dot com>
- Date: Fri, 12 May 2000 10:15:13 -0400
- CC: Zack Weinberg <zack at wolery dot cumb dot org>, Neil Booth <NeilB at earthling dot net>, thorpej at zembu dot com, gcc-bugs at gcc dot gnu dot org
- Organization: Red Hat
- References: <200005121744.SAA10400@cam-mail2.cambridge.arm.com>
Richard Earnshaw wrote:
> We were trying to avoid that particular contortion, but there are several
> other reasonable solutions.
>
> #define IMMED(x) # ## x
> #define wibble(foo) mov r0, IMMED(foo)
Not legal -- the token following # must be the name of a macro argument
> or
>
> #define wibble(foo) mov r0, # ## foo
Same as previous
> or
>
> #define wibble(foo) mov r0, #(foo) /* If brackets ok */
Same as previous
> or
>
> #define wibble(foo) mov r0, # /**/ foo /* I think... not tested */
Nope -- will still output "4"
> or
>
> #define IMMED(x) x
> #define wibble(foo) mov r0, #IMMED(foo)
Not legal -- see above
Any legal solution will involve getting the # out of the replacement of a
function-like macro. This can only be done by substituting it using another
macro. An object-like macro or a macro argument can't be used for this unless
whitespace is tolerated between the # and the number. At the moment, the solution
I proposed is the only one I can think of in the case where there can be no
whitespace.
Dave