cpp problem in recent snapshots, alpha linux

[Zack Weinberg]

On Thu, Mar 02, 2000 at 02:00:06PM -0800, Robert Read wrote:
> One of the include files in XFree86 does something like this:
> 
> #define ProjName proj
> #define Concat3(a,b,c) a##b##c
> #define IncFile Concat3(<,ProjName,.h>)
> #include IncFile
> 
> Notice the < and > in the macro.  Is there something wrong with this
> code? It works fine on older gcc, but not with recent snapshots.
> The error I'm getting is:
> 
> $ gcc -E t1.h
> t1.h:4:16: macro `Concat3' used with just one arg
> t1.h:4:16: ,ProjName,.h: No such file or directory
> 
> It looks like cpp is treating the bare < and > differently now.
> Running on Alpha Linux, snapshot 20000228.

This is an interesting situation; thanks for pointing it out.

The C standard doesn't nail down the behavior of the above example;
it's either flat undefined, or implementation-defined.  I'm not sure.
I will ask for an interpretation in comp.std.c.

What's happening is that IncFile is expanded in the context of an
#include, which means that <,ProjName,.h> is treated as a *single*
string token, not the sequence < , ProjName , . h > that you wanted.  So
Concat3 sees only one argument.  Furthermore, ProjName doesn't undergo
macro replacement.

Even if the args of Concat3 were tokenized the way you wanted, you
might then invoke undefined behavior by attempting to paste
< ProjName . h > together - depending on the interpretation, that
might or might not be "the result of token paste is not a legal
token".

My personal opinion is, when you use #include MACRO, MACRO should
always be defined to just a single "..." or <...> sequence.  It may
not even be safe to use <...>.

zw