Re: preprocessor/8120: cpp concatenation doesn't work as described

Re: preprocessor/8120: cpp concatenation doesn't work as described

[Neil Booth]

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.

Re: preprocessor/8120: cpp concatenation doesn't work as described

[neil]

Synopsis: cpp concatenation doesn't work as described

State-Changed-From-To: open->closed
State-Changed-By: neil
State-Changed-When: Sat Oct  5 02:39:30 2002
State-Changed-Why:
    Documentation updated.

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

preprocessor/8120: cpp concatenation doesn't work as described

[Peter Breitenlohner]

>Number:         8120
>Category:       preprocessor
>Synopsis:       cpp concatenation doesn't work as described
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Wed Oct 02 02:46:01 PDT 2002
>Closed-Date:
>Last-Modified:
>Originator:     Peter Breitenlohner <peb@mppmu.mpg.de>
>Release:        3.2
>Organization:
Max-Planck-Institut fuer Physik, Munich, Germany
>Environment:
System: Linux pcl321 2.4.17 #1 Sat Feb 23 15:19:54 CET 2002 i686 unknown
Architecture: i686

	
host: i586-pc-linux-gnu
build: i586-pc-linux-gnu
target: i586-pc-linux-gnu
configured with: ../gcc-3.2/configure --host=ix86-linux-gnulibc2 --prefix=/usr --disable-nls --enable-shared --enable-languages=c++,f77,objc --bindir=/ix86-linux-gnulibc2/bin
>Description:
cpp.info-> Implementation Details
	-> Obsolete Features
	-> Miscellaneous obsolete features
	-> Attempting to paste two tokens which together do not form
	   a valid preprocessing token.
Says (quoted literally):

The preprocessor currently warns about this and outputs the two
tokens adjacently, which is probably the behavior the programmer
intends.  It may not work in future, though.

Most of the time, when you get this warning, you will find that
`##' is being used superstitiously, to guard against whitespace
appearing between two tokens.  It is almost always safe to delete
the `##'.

(end quote)

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!!

Of course, the second paragraph quoted above applies: `name ## .h' should
be replaced by `name.h' which equally works with gcc-2.95.3 and gcc-3.2
(without any warnings).
>How-To-Repeat:
See above
>Fix:
See above
>Release-Note:
>Audit-Trail:
>Unformatted: