[cfe-dev] #define behavior

'Neil Booth' neil at daikokuya.co.uk
Thu Dec 6 06:53:24 PST 2007


Hartmut Kaiser wrote:-

> > Standard C works on tokens, not text, so the code is invalid as
> > * and = are two separate tokens.
> 
> The preprocessor works on preprocessor tokens (translation phase 4), which
> are different from the tokens the compiler is working on. The preprocessor
> tokens are converted into tokens at translation phase 7 only. Any
> preprocessor token not matching the syntax of a token is an error at this
> point.

Well, is undefined behaviour.  The standard has no concept of error per
se, only "must be diagnosed" and "failure to successfully translate",
the latter applying to #error exclusively.

> Further, IIUC concatenating two tokens (using ##) forming another (invalid)
> pp token results in undefined behaviour in C90/C++ but is allowed in
> C99/C++09. Gcc issues a warning here (I'm not sure about clang) for C90/C++.

There is no difference between C90 and C99 here.  I'm the person that
made it a hard error in GCC; it is not a warning.  That is and was my
preference.  :)
 
> Juxtapositioning two preprocessor tokens generally doesn't create a new
> preprocessor token. So the two preprocessor tokens '*' and '=' are converted
> to tokens separately (in translation step 7), resulting in the syntax error
> above.
> 
> When the textual representation of the preprocessed input is to be generated
> (i.e. gcc -E) all good preprocessors _insert_ additional whitespace between
> two preprocessor tokens, which otherwise would form another token based on
> juxtaposition, just to avoid creating the syntax of a different token from
> juxtapositioning two preprocessor tokens. 
> 
> IMHO, gcc and clang (and FWIW, wave) behave correctly.

Absolutely.  I was just expressing it in plain English.

Neil.



More information about the cfe-dev mailing list