On Thu, 27 Nov 2025, Florian Weimer via Gcc wrote: > It looks like that as part of C standard maintenance, there is not much > impact analysis on the changes that go into the standard. There does
Sometimes people suggest referring a particular proposal to the C++ liaison group, but really this depends on someone noticing the compatibility issue when writing or reviewing the proposal. If people have concerns about a name to start with they may investigate what names are already in used with what meanings (see e.g. the discussions that led to _Countof), but if a name is commonly used with the meaning to be adopted into the standard, it might be desirable to use the same name (even though that could break code already defining such an identifier). > not seem to be anything like what we did before we changed GCC to > enforce more typing rules. Furthermore, the current C Standard charter > has dropped the principle to minimize incompatibilities with C++, which > is challenging for glibc given that it is so often used together with > C++. New keywords in C23 such as bool, true and false were *increasing* compatibility with C++ (though breaking compatibility with lots of pre-C99 C code defining its own version of bool). The const-generic macros recently added that broke some things that weren't const-safe for those functions were *increasing* compatibility with C++. Improving C++ compatibility does not necessarily mean improving compatibility with existing C code. > As a result, upgrading to a newer version of glibc that implements more > C features tends to break a lot of software, including the Linux kernel. > Yet we don't want to delay completing the implementation of new > standards in glibc. I don't think it's clear it breaks more than you might expect from C language feature changes, or from changes to C++ language version. > Currently, we enable everything with -D_GNU_SOURCE. As GCC 15 defaults > to C23 (via the implied -std=gnu23), even with _DEFAULT_SOURCE (without > -D_GNU_SOURCE or any feature macros defined), users are exposed to > library functionality that has problematic compatibility with existing > application sources. As an additional wrinkle, GCC defaults to > -D_GNU_SOURCE in C++ mode. > > I think we should change the meaning of _GNU_SOURCE, perhaps even attach > a version to it. For _DEFAULT_SOURCE, we need to detect if the > standards version specified implicitly or explicitly. If the standard > is selected implicitly, we should only enable the safe defaults > (perhaps: those implemented at the time when GCC switched defaults). If someone uses -std=c23 (thus, __STRICT_ANSI__ and no default _DEFAULT_SOURCE), of course they should get C23 library features as well as language features. It would seem very odd for -std=gnu23 to provide fewer C23 library features than -std=c23, or for default -std=gnu23 to behave differently from explicit -std=gnu23. > I think the recent decision to disable once_flag in C++ mode even with > _GNU_SOURCE goes in the right direction. We should consider doing that > for C as well, given that we have a perfectly compatibile alternative in > <pthread.h>. The point of once_flag in <stdlib.h> is to have something portable to non-POSIX systems (and not depending otherwise on support for C11 threads). -- Joseph S. Myers [email protected]
