https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82528
Eric Gallager <egallager at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution|--- |DUPLICATE
--- Comment #3 from Eric Gallager <egallager at gcc dot gnu.org> ---
(In reply to Martin Sebor from comment #2)
> Yes, I also thought of bug 82272. The challenge with having the macros true
> and false expand to some built-ins (like __true and __false) is that it
> would be at odds with the C requirements that they be suitable for use in
> #if preprocessing directives and expand to the integer constants 1 and 0.
> At a minimum, the preprocessor would need to be made aware of these
> built-ins. The more esoteric problems stemming from having them expand to
> non-literals is in preprocessor tricks like:
>
> #include <stdbool.h>
>
> #define CAT(a, b) a ## b
> #define CONCAT(a, b) CAT (a, b)
>
> int i = CONCAT(1, true);
>
> It's not clear that the standard actually requires the above to expand to
> '11' (as opposed to causing an error if true were defined to (1), i.e., 1 in
> parentheses) so maybe this is a non-issue. As H. Peter Anvin suggests in
> the related bug, it might be helpful to get this clarified and perhaps even
> tightened up for C2X.
The discussion seems to be more in 82272 so I guess that's the one this is a
dup of.
*** This bug has been marked as a duplicate of bug 82272 ***
