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 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++.
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 think we we want to encourage end users to be able to build their own software using an up-to-date GNU toolchain. This means we need to explore ways to gradually phase in standards, as available source code adopts new standards. 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). We could enable more GNU functionality by default, so that programmers rarely have to define _GNU_SOURCE. Then _GNU_SOURCE could perhaps enable everything. Although today, this is problematic for C++ source due to GCC's _GNU_SOURCE default. 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>. Thoughts? Thanks, Florian
