On Mi, 2016-06-01 at 11:22 -0700, Paul Eggert wrote: > On 06/01/2016 01:29 AM, David Seifert wrote: > > > > stdbool.m4 is supposed to merely check that > > stdbool.h fulfills C99 requirements. Why does it then necessarily > > check whether bool is a > > defined _macro_? > Because C99 (and C11) require bool to be a macro. > > m4/stdbool.m4 now does that check only inside #if __cplusplus < > 201103, > so I don't see why clang++ would complain now. Is it setting > __cplusplus > to an older value? Do older versions of the C++ standard require bool > to > be a macro? (I don't use C++.)
Clang++ hasn't made the switch to a post -std=c++98 world yet. This means that literally every ./configure with CC=clang++ will fail. The crux of the matter is that clang/LLVM will only ever define bool/true/false as macros if __GNUC__ is defined, which is imo unrealistic. C++98 never required nor explicitly defined bool/true/false to be macros, mainly because they are proper types/literals in C++. > > > > Wouldn't it be better to change the stdbool.m4 macro to instead > > try > > and use "bool" in a statement > > or as a type > It depends on how strict the compatibility checking should be. Kind > of a > judgment call, I suppose. That being said, I don't see the harm in > the > current approach for C. Maybe it needs to be toned down for C++, but > I'd > like to know why before fiddling with this (it's been this way since > at > least 2002...). > We could relax the whole thing a bit, and maybe just make a plain __cplusplus check, without a version number. This keeps the C side as it always has been, but allows C++'s proper literals to kick in. In addition, _Bool is also a major obstacle, as it does not exist in C++ (and does so only for GCC due to some GNUisms in libstdc++ with -std=c++98). Would you consider moving away from _Bool and replacing all uses of it with bool? After all, <stdbool.h> by itself only mandates the existence of bool/true/false.
