Question

The following preprocessor macro:

#define _VARIANT_BOOL /##/

is not actually valid C; roughly speaking, the reason is that the preprocessor is defined as working on a stream of tokens, whereas the above assumes that it works on a stream of characters.

On the other hand, unfortunately the above actually occurs in a Microsoft header file, so I have to handle it anyway. (I'm working on a preprocessor implementation.)

What other cases have people encountered in the wild, be it in legacy code however old as long as that code may be still in use, of preprocessor macros that are not actually valid, but work anyway because they were written under compilers that use a character oriented preprocessor implementation?

(Rationale: I'm trying to get some idea in advance how many special cases I'm going to have to hack, if I write a proper clean standard-conforming token oriented implementation.)

Was it helpful?

Solution

The relevant part of the standard (§6.10.3.3 The ## operator) says:

If the result is not a valid preprocessing token, the behavior is undefined.

This means that your preprocessor can do anything it likes and still be standard conforming, including emulating the common behaviour.

I think you can still have a "token-based" implementation and support this behaviour, by specifying that when the result of the ## operator is not a valid preprocessing token, the result is the two operand tokens unchanged. You may also want to have your preprocessor emit a warning about the invalid code.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top