This is the mail archive of the
gcc-prs@gcc.gnu.org
mailing list for the GCC project.
Re: preprocessor/8120: cpp concatenation doesn't work as described
- From: Neil Booth <neil at daikokuya dot co dot uk>
- To: nobody at gcc dot gnu dot org
- Cc: gcc-prs at gcc dot gnu dot org,
- Date: 4 Oct 2002 22:16:01 -0000
- Subject: Re: preprocessor/8120: cpp concatenation doesn't work as described
- Reply-to: Neil Booth <neil at daikokuya dot co dot uk>
The following reply was made to PR preprocessor/8120; it has been noted by GNATS.
From: Neil Booth <neil@daikokuya.co.uk>
To: Peter Breitenlohner <peb@mppmu.mpg.de>
Cc: gcc-gnats@gcc.gnu.org
Subject: Re: preprocessor/8120: cpp concatenation doesn't work as described
Date: Fri, 4 Oct 2002 23:08:38 +0100
Peter Breitenlohner wrote:-
> I was using the following code, cut down to the bare essentials and
> replacing `#include' by `include' in order to (a) get some output from the
> preprocessor and (b) make visible what happens.
> ################## start of input file bug.c ####################
> #define XXX_H(name) XXX_I(prefix_ ## name ## .h)
> #define XXX_I(file) #file
>
> include XXX_H(all)
> ################### end of input file bug.c #####################
> The command `gcc -E bug.c -o bug.i' yields
> ################## start of output file bug.i ###################
> # 1 "bug.c"
> # 1 "<built-in>"
> # 1 "<command line>"
> # 1 "bug.c"
>
>
>
> include "prefix_all .h"
> ################### end of output file bug.i ####################
> together with the warning:
> bug.c:4:18: warning: pasting "prefix_all" and "." does not give a valid
> preprocessing token
>
> The warning is in agreement with the above quote, but the output is not,
> since the two tokens `prefix_all' and `.' are separated by a space (and
> subsequently stringified).
>
> This construct used to produce "prefix_all.h" with gcc-2.95.3 (without
> warning). With gcc-3.1.1 and 3.2 I got the desired result (with a warning) when
> I replaced `name ## .h' by `name ##.h' or by `name##.h', but not with
> `name## .h'. I would think something funny happens here with the handling of
> whitespace!!
I will correct the documentation to say "gives undefined behaviour"
shortly. 3.3 gives a hard error. To get the result you want, remove the
offending ##.
Neil.