GCC Preparing To Set C23 "GNU23" As Default C Language Version (www.phoronix.com)
from JRepin@lemmy.ml to programming@programming.dev on 17 Oct 08:44
https://lemmy.ml/post/21488815

cross-posted from: lemmy.ml/post/21458338

The GNU Compiler Collection (GCC) support for the C23 programming language standard is now considered “essentially feature-complete” with GCC 15. As such they are preparing to enable the C23 language version (using the GNU23 dialect) by default for the C language version of GCC when not otherwise specified.

Preparations are now underway to set the default C language version of GCC to GNU23 as the GNU dialect of C23. Or in other words, implying -std=gnu23 when no other C standard is specified.

#programming

threaded - newest

BB_C@programming.dev on 17 Oct 09:35 collapse

That’s good and all, but we all explicitly pass -std=gnu99 (or -std=c99 if you don’t care about MSYS2 compat) in our build scripts buddy 😉

Okay, maybe not all all. But you get the idea.

Are there any relevant projects who use the increasingly C+±infested newer versions of the language?

thingsiplay@beehaw.org on 17 Oct 14:24 next collapse

I’m not a C programmer, but looking at the changes and improvements, there are lot of good advancements I would not want to miss out on: C11 (C17 just fixes a few little issues from C11) > C23

Stuff like Multi-threading support, Improved Unicode support, Add memccpy() and whats so bad about Various syntax changes improve compatibility with C++? C doesn’t exist in a vacuum. If you don’t want learn the new changes or do not want rely on it because of compatibility reasons, I can understand. But why would you not use newer C versions, if there is no compatibility with older version “required”?

BB_C@programming.dev on 17 Oct 16:32 collapse

Multi-threading support

Who stopped using pthreads/windows threads for this?

Unicode support

Those who care use icu anyway.

memccpy()

First of all, 😄.
Secondly, it’s a library feature, not a language one.
Thirdly, it existed forever in POSIX.
And lastly, good bait 😄.

whats so bad about Various syntax changes improve compatibility with C++

It’s bad because compiler implementations keep adding warnings and enabling them by default about completely valid usage that got “deprecated” or “removed” in “future versions of C” I will never use or give a fuck about. So my CI runs which all minimally have -Wall -Werror can fail with a compiler upgrade for absolutely irrelevant stuff to me. If it wasn’t for that, I wouldn’t even know about these changes’ existence, because I have zero interest in them.

Those who like C++ should use C++ anyway. They can use the C+classes style if they like (spoiler alert: they already do).

I can understand. But why would you not use newer C versions, if there is no compatibility with older version “required”?

Because C doesn’t exist in a vacuum, and Rust exists. Other choices exist too for those who don’t like Rust.

My C projects are mature and have been in production for a long time. They are mostly maintenance only, with new minor features added not so often, and only after careful consideration.

^Still^ ^interested^ ^in^ ^knowing^ ^what^ ^relevant^ ^projects^ ^will^ ^be^ ^using^ ^C23.^

zarenki@lemmy.ml on 17 Oct 20:31 collapse

Newer than C99? Both the Linux kernel and systemd build with gnu11. I’d call those pretty relevant.

C23 is still far too new (still a draft) for any major projects that care about compiler compatibility.