A unexpected result on string concatination with ANSI preprocessor

Zack Weinberg zack@bitmover.com
Tue Aug 31 22:45:00 GMT 1999


Manabu Higashida wrote:
> On hpux11.00, there are standard macros in "/usr/include/inttypes.h"
> like this,
> 
>   #define __CONCAT__(_A,_B) _A ## _B
>   #define __CONCAT_U__(_A) _A ## u
>   #define UINT32_C(__c)                    __CONCAT__(__CONCAT_U__(__c),l)
> 
> and the preprocessor with gcc-2.9x could not process a result of
> expected.  

The behavior of gcc's preprocessor is correct; the hpux11 preprocessor
does not conform to the C standard.

The macros defined above will expand like this.  I've inserted spaces
between all the tokens, to make it clearer what's going on.

UINT32_C ( type )	-> __CONCAT__ ( __CONCAT_U__ ( type ) , l )

The argument of UINT32_C is macro-expanded now, before any other
processing.  `type' is not #defined to anything, so we proceed to
expand __CONCAT__.

			-> __CONCAT_U__ ( type ) ## l

The arguments of __CONCAT__ are *not* expanded now, because ##
inhibits that step.  The token paste is executed immediately,
producing

			-> __CONCAT_U__ ( type )l

")l" is not a legal single token, so it is treated as two tokens:

			-> __CONCAT_U__ ( type ) l

*Now* __CONCAT_U__ is expanded:

			-> type ## u l

and token paste produces:

			-> typeu l

A correct definition of UINT32_C would be simply

#define UINT32_C(__c) __CONCAT__(__c, ul)

with the same definition of __CONCAT__.  You should report a bug in
hpux's compiler and include files.  We might consider adding logic to
`fixincludes' to work around the problem, but you'd have to give a lot
more detail.

zw



More information about the Gcc-bugs mailing list