C preprocessor: what is the motivation behind not macro-expanding arguments of #error directive?

Viewed 108

What is the motivation / rationale behind not macro-expanding arguments of #error (and #warning) directive?

The gcc documentation explicitly states:

Neither ‘#error’ nor ‘#warning’ macro-expands its argument.

P.S. For #warning (not standardized) the fix is to use #pragma message (https://stackoverflow.com/a/12638158/1778275), which (normally) macro-expands its arguments.

UPD. The question is not specifically about why gcc does not perform macro-expantion. The quote from gcc documentation is used as an example of text, which explicitly states that neither #error nor #warning macro-expands its argument. I could not find this (or similar) text in C standard. Hence, refer the quite from gcc documentation.

UPD2. In comparison with #error the #include performs macro-expantion of its arguments. Quote from the standard (ISO/IEC 9899:202x (E)):

The preprocessing tokens after include in the directive are processed just as in normal text. (Each identifier currently defined as a macro name is replaced by its replacement list of preprocessing tokens.)

1 Answers

I don't say this is the motivation for the standard, but thinking of many of my uses of #error it would be inconvenient to have it macro-expanded.
Admittedly, my habits might have been formed by the non-expansion.

#define MINIMUMCONFIG 1
#ifndef IMPORTANTCONFIG
#error  IMPORTANTCONFIG is undefined!
#error
#if     IMPORTANTCONFIG < MINIMUMCONFIG
#error  IMPORTANTCONFIG lower than MINIMUMCONFIG !
#endif
Related