[Bug preprocessor/38161] [4.4 regression] #elif non-const expression #defined in this #if breaks

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38161

Jakub Jelinek jakub at gcc dot gnu.org changed:

   What|Removed |Added

 CC||signupnathan at gmail dot com

--- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org ---
*** Bug 57345 has been marked as a duplicate of this bug. ***

[Bug preprocessor/38161] [4.4 regression] #elif non-const expression #defined in this #if breaks

[harald at gigawatt dot nl]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38161

Harald van Dijk harald at gigawatt dot nl changed:

   What|Removed |Added

 CC||harald at gigawatt dot nl

--- Comment #6 from Harald van Dijk harald at gigawatt dot nl ---
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?

[Bug preprocessor/38161] [4.4 regression] #elif non-const expression #defined in this #if breaks

[pinskia at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38161

--- Comment #7 from Andrew Pinski pinskia at gcc dot gnu.org ---
*** Bug 57345 has been marked as a duplicate of this bug. ***

[Bug preprocessor/38161] [4.4 regression] #elif non-const expression #defined in this #if breaks

[rguenth at gcc dot gnu dot org]

--- Comment #4 from rguenth at gcc dot gnu dot org  2008-12-05 12:20 ---


*** This bug has been marked as a duplicate of 36453 ***


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||DUPLICATE


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38161

[Bug preprocessor/38161] [4.4 regression] #elif non-const expression #defined in this #if breaks

[neil at gcc dot gnu dot org]

--- Comment #3 from neil at gcc dot gnu dot org  2008-11-18 22:18 ---
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.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38161

[Bug preprocessor/38161] [4.4 regression] #elif non-const expression #defined in this #if breaks

[tromey at gcc dot gnu dot org]

--- Comment #1 from tromey at gcc dot gnu dot org  2008-11-17 17:29 ---
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.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38161

[Bug preprocessor/38161] [4.4 regression] #elif non-const expression #defined in this #if breaks

[h dot b dot furuseth at usit dot uio dot no]

--- Comment #2 from h dot b dot furuseth at usit dot uio dot no  2008-11-17 
20:15 ---
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.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38161