* Joseph Myers: > 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++.)
The warning might encourage developers to plan for the transition and think about the ABI impact. I think we should try to bring across the message that this isn't just about fixing build failures. > 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. Even the char definition is not fully ABI-compatible with _Bool and can introduce undefined behavior on a switch to _Bool if not everything is recompiled.
