I think this program should emit a warning in C mode: #define TRUE ((_Bool) 1) #define FALSE ((_Bool) 0) typedef enum { a, b, c } result; result f (int flag) { if (flag) return TRUE; else return FALSE; } Likewise, this should warn as well: #include <stdbool.h> typedef enum { a, b, c } result; result f (int flag) { if (flag) return true; else return false; } This may require the definition of __true and __false as compiler built-ins, similar to what exists for NULL in the C++ front end, so that the compiler can keep up the fiction that true and false are the integer constants 1 and 0 (apparently, false is a valid NULL pointer constant, but warning about false where NULL could be used seems reasonable to me).
I see you already have bug 78736 under "See Also", but bug 82272 is also related. Probably a dup of one of those 2, but since I can't decide which, confirmed.
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.
(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 ***