* Joseph Myers: > 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).
Sometimes, common identifiers are hidden by default behind macros like __STDC_WANT_IEC_60559_BFP_EXT__, for example iszero (if I read the sources correctly). I assume the committee does not perform a compatibility impact analysis for those cases because they require an explicit opt-in. Historically, _GNU_SOURCE turns on those features, too. >> 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. I meant that minimizing C++ incompatibles is no longer called out as a separate principle. >> 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. C developers are probably not used to it, due to how long GCC parked on C99 (and in some ways, K&R) out of source code compatibility concerns. Changes to core C headers also seemed quite rare, with larger changes going into new headers like <threads.h> instead (or being hidden behind feature macros, but that does not seem to matter to us). C++ also benefits from GCC tying itself to a specific libstdc++ version automatically, so it's easier to have a custom build of GCC and keep using that for maximum source-level compatibility. But the -std= switch affects the standard library headers quite profoundly, so you might not need a separate compiler installation after all. _GNU_SOURCE does not act as a de-facto override for -std= selection as far as the C++ library is concerned. >> 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. That seems to rule out relying on any of the existing mechanisms. The defaults may matter less (although the optics aren't great) than a way to go back in time if necessary. Using -std=gnu17 does not have the intended effect for pure library additions. I think you'd need a separate glibc installation to go back in time. This isn't great for someone who just wants to build some software. Removing -Werror is not always sufficient for that (or easy); there were reported problems where changing something from a function to a macro causes problems. This is less of an issue for C++ because it's possible to effectively go back to earlier headers using -std=. The C++ default does not change until the libstdc++ side is complete, so it's less likely that there is code out there that requires something newer than C++17 (perhaps by accident), but cannot deal with all the changes that come through C++20. >> 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). Still it's a very poor trade-off for us. There must be very little code out there which is routinely compiled against glibc *and* is portable systems without threading support *and* the target systems have a realistic chance of getting upgraded to C23 on a reasonable time scale (or at all). Thanks, Florian
