On Wed, 16 Oct 2024, Florian Weimer wrote: > * Jakub Jelinek via Gcc: > > > Are some of the papers/features known to be fully implemented (since which > > version)? E.g. for __VA_OPT__ I remember doing (and Jason too) various > > fixes > > in the past few years, like PR89971, PR103415, PR101488. Not really sure > > what exactly C23 requires. > > Can we add a warning if bool is defined to anything that isn't _Bool > (either as a macro or as a type)? If we are serious about switching > to C23 by default, I think that warning needs to be enabled by > default, due to the ABI impact.
In -std=gnu23 mode, defining bool as a typedef will result in an error anyway. (Defining a macro with any of the names alignas, alignof, bool, false, static_assert, thread_local, true is undefined behavior in C23, so it's certainly OK to diagnose defining such a macro, even as a pedwarn / error, if we wish.) I'm not sure such a warning particularly helps, however; any ABI incompatibility occurs at the point where someone changes their code to stop defining bool and to use the standard bool instead. (And any problem code would already have been ABI-incompatible with C++.) Several of the tests I added -std=gnu17 to had their own definitions of bool as an enum with values false and true, but I think that comes from reduction of preprocessed source from GCC 2.95 (which had such a definition, arising from older C9X drafts, in its <stdbool.h>) rather than being something likely to occur in user code. I expect "typedef char bool;" (or "#define bool char"), and similar with unsigned char, to be much more common in applications. -- Joseph S. Myers josmy...@redhat.com
