Re: GCC Pre-processor bug?

[Dave Brolley <brolley at redhat dot com>]

nismo@freeuk.com wrote:

> Consider the following Imake.tmpl and Imakefile:
>
> /************************************************** Start of Imake.tmpl */
> #define Concat3(a,b,c)a/**/b/**/c
>
> #include INCLUDE_IMAKEFILE
> /**************************************************** End of Imake.tmpl */
>
> /*************************************************** Start of Imakefile */
> #define PathChar /
>
> DIRNAME=Concat3(Parent,PathChar,Child)
> /***************************************************** End of Imakefile */
>
> The problem is that when gcc is run with the "-traditional" flag, the output
> within the resultant "Makefile" looks as follows:
>
> ParentPathCharChild
>
> which is wrong. What I'm trying to get is:
>
> Parent/Child
>
> and the reason I'm not getting it is because macro expansion for parameters
> of the Concat() macro is being attempted *after* the expansion of the macro
> itself. Shouldn't it be done before? Is this intentional?

In my experience, traditional preprocessors do not pre-expand macro arguments
before substitution. This is an ANSI/ISO behaviour. Even then ANSI/ISO
preprocessors do not pre expand arguments if the corresponding parameter is the
operand of the # or ## operators.


> The definition of Imake.tmpl can be changed to the following in an attempt
> to fix the problem. This fix works on some other compilers, but not on gcc:
>
> /************************************************** Start of Imake.tmpl */
> #define _Concat3(a,b,c)a##b##c
> #define Concat3(a,b,c)_Concat3(a,b,c)
>
> #include INCLUDE_IMAKEFILE
> /***************************************************** End of Imakefile */
>
> The idea is that a double macro invokation causes the parameters of the
> original Concat() macro to be expanded before before the bucket invokation
> of the _Concat() macro with identical parameters. Now when you run Imake
> the Makefile contains:
>
> Parent##/##Child
>
> which is still not correct. The reason the "/" appeared, however, was
> because the sequence "PathChar" was recognisable in the intermediate stage:
>
> Parent##PathChar##Child

Right .... because traditional preprocessors do not know about ##

> However, if I butcher "Imake" and remove the "-traditional" option from the
> gcc command line, we now get:
>
>   Parent/Child
>
> which is correct *except* for the spurious whitespace on the front. Each
> macro expansion that is done generates a spurious leading whitespace! This
> makes usage of this macro impossible if the expanded output of the macro
> needs to start from column one.

I would consider this to be a bug.

> I would appreciate any comments and details of any known workarounds, if
> there are any.

With traditional, you need not use a macro to concatenate. Just use comments in
open text, as in

  #define PathChar /

  DIRNAME=Parent/**/PathChar/**/Child

Traditional cpp should expand the macro and remove the comments leaving

  DIRNAME=Parent/Child

Dave