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