Re: [Devel] Re: Summary of ANSI preprocessor trouble..

[Antoine Leca]

David Turner wrote:
> 
>   the following lines do not compile with LCC:
> 
>     #define  PATH(d,x)  <##d##/##x##>
>     #define  MY_FILE_H   PATH(mydir,myfile)
> 
>   the compiler complains that ## produced an invalid _token_,
>   named "<mydir". It seems that LCC really insists that
>   _every_ concatenation creates a "valid" token, instead
>   of checking only the end result.

The standard perfectly allows it to go this way.

Ritchie's cpp will also choke here (which means you cannot
port to Plan 9... :-( ). This is no surprise, as Navia's lcc-win32
reuses (while modified) a previous version of Ritchie's cpp.

 
>   the following do work well with LCC however:
> 
>     #define  PATH(d,x)   <d/x>
>     #define  MY_FILE_H   PATH(mydir,myfile)
> 
>   However, some other compilers will probably complain about it,

This is possible (the standard allows that), but seems unprobable
to me.

>   or simply produce "<d/x>" instead of "<mydir/myfile>"

This is not possible: cpp cannot "know" that <d/x> is intended to
be used as a header name.
Also the standard says explicitely that in the form
#include PATH(mydir,myfile), macro subtitutions are to be performed.
An example is even provided. So this is not likely to be left
unimplementated in not-so-compliant compilers.

 
>   I have thus tried something like:
> 
>     #define  ENCLOSE_IN_ANGLES(x)    <x>
>     #define  INSERT_DIR_SEP(d,x)     d/x
>     #define  PATH(d,x)               ENCLOSE_IN_ANGLES(INSERT_DIR_SEP(d,x))

I do not see a reason for the former to fail and the later to work
(the reason for the former to fail would be a retive compiler that
insist on adding spaces even when they are not necessary, for
example after the < to prevent the possible creation of a <<.
And in this case, they are likely to do it in either case).

OTOH, the change is pretty harmless, IMHO.


Antoine