GCC Bugzilla – Bug 38161
[4.4 regression] #elif <non-const expression #defined in this #if> breaks
Last modified: 2013-05-20 22:52:54 UTC
#define FOO sizeof(void *)
t.c:3:7: error: missing binary operator before token "("
I expect it's caused by the fix to bug #36320.
According to my reading of the standard, this code is in fact incorrect.
This is basically the same as #36320.
I'm beginning to wonder, though, whether this change was overly eager on my part
and should be made -pedantic only, or something like that.
Subject: Re: [4.4 regression] #elif <non-const expression #defined in this #if> breaks
Yes, I should have read the #36320 text more carefully. I merely
noticed that its empty #elif cannot expand to anything correct, while
my example can (and does in the real-life case which produced it).
I thought C99 6.10p7 was what saved it:
The preprocessing tokens within a preprocessing directive are
not subject to macro expansion unless otherwise stated.
but maybe not. 6.10.1p3 doesn't say anything about some #elif branches
not being evaluated:-( Hopefully that's just overly standard-lawerly
though. Maybe comp.std.c would have been a better place to ask.
The standard talks about the groups controlled by conditionals being skipped.
There is no conditional controlling the #elif - it is at the top level - so I see nothing permitting its non-evaluation.
*** This bug has been marked as a duplicate of 36453 ***
*** Bug 57345 has been marked as a duplicate of this bug. ***
Given that the standard apparently unintentionally requires this behaviour, and the standard will likely be changed to require FOO to not be evaluated (see <http://www.open-std.org/JTC1/SC22/WG14/www/docs/dr_412.htm>), perhaps the pre-4.4 behaviour should be restored, or at least the diagnostics downgraded to a warning?