On Tue, 28 May 2024, Jakub Jelinek via Gcc wrote: > -std=gnu23 support is still incomplete even in GCC 14. It doesn't involve ABI issues, however, unlike C++, so using the option with GCC 14 is comparatively safe. (It might run into a few aliasing bugs related to tag compatibility right now, but hopefully we'll have fixes for those backported for 14.2 as wrong-code issues. And of course code testing __STDC_VERSION__ with GCC 14 or before needs to handle incompleteness of the implementation.) Once we have #embed implemented (and so are substantially feature-complete, modulo the optional standard function attributes [[unsequenced]] and [[reproducible]]) it should be reasonable to change the default to -std=gnu23 (though we'll need to see what the distribution build impact from such a change is, especially regarding bool, true and false becoming keywords). This certainly doesn't guarantee there won't be future C features with ABI issues from using an unstable version, however (if some C2y draft adds a new feature, then it's implemented, then the specification changes in an ABI-incompatible way - for an old example, consider how early C9x drafts had an enum-based definition of _Bool, which changed later to a built-in type like in C++, thereby changing from the size of int to a single byte). Indeed the API for some library functions in TS 18661-1 changed for the versions in C23, but that can be handled in glibc through symbol versioning (done some time ago for the totalorder functions, not yet done for fromfp functions). -- Joseph S. Myers josmyers@xxxxxxxxxx
