Fedora Linux Cleared To Pursue Its Modern C Porting

[SledgeHammer_999]

While I understand porting away from C is non-trivial, if they're going to be putting in this much effort to modernize

You're wrong. It isn't that much effort.
Let me explain.
What they intend to do is to basically configure the compiler to adhere to the new C standard and start throwing warnings for code that isn't standards compliant. They will treat those warnings as errors and will go back to fix them to be standards compliant.
If you look at the proposal wiki the incompatibilities are "easy" to locate and fix. The hard part is they are a lot of them.
It would be way harder to move to another language.

PS: IMO, if you're going to do a language rewrite from a C codebase, it would make much more sense to move to modern C++. You'll get to re-use some of the C code and you'll also get the benefit of modern C++ (type safety, classes, way better memory management and safety (RAII, smart pointers), STL, templates, modules).

[Volta]

[...] they might as well take the extra step and modernize all the damned way to some specified memory safe language. I am not necessarily saying Rust. There's more out there that fill this category than just Rust so don't start jumping on the Rust high horse for advocacy. I don't particularly care which one it is.

Yeah, keep dreaming. Rust seems to be an only eligible alternative (in some way). You can burn everything else in fire.

The NSA[...]

The NSA should be put to /dev/null. Together with your tinfoil hat ideas.

[microcode]

Is there some actual good technical reason why GCC is doing this?

[jabl]

Modern C.
23 year old standard.

Couldn't they go straight away C11?

The GCC (and I think clang too?) default these days is gnu17, that is C17 with GNU extensions. So even without any explicit -std= flag it's fine to use C17 features.

What they're discussing about now is that GCC and LLVM want to remove some obsolete constructs from gnu17 that were removed in C99 but kept as part of the "GNU extensions" for backwards compatibility reasons. I don't think any features were removed from C11/17 so hence the discussion revolves around features that C99 prohibited from the language.

[jabl]

Is there some actual good technical reason why GCC is doing this?

The features they want to outlaw are, even by C standards, footguns, and the hope is that by generating errors instead of accepting such code it will lead to less buggy code (potentially including bugs that can be exploited).

[bug77]

What does C++ have to do with this article? Are you one of those people that think C and C++ are the same thing?

They're both systems programming languages that Rust has a chance to displace, that's all.

[bug77]

That just shows how stable C is. Look at that, the standard they're throwing out is ANSI C, which in many ways was transitional between pre-standard C and "modern" C. At that time, all those newfangled languages didn't exist yet (Python came in 91, JavaScript in 95, Java and OCaml in 96). We must continue writing C for all eternity, because otherwise there is not enough potential for disastrous bugs.

Somehow having to sit on a standard for 20+ years before using it confidently doesn't strike me as "stable". Quite the opposite.

[erniv2]

The GCC (and I think clang too?) default these days is gnu17, that is C17 with GNU extensions. So even without any explicit -std= flag it's fine to use C17 features.

What they're discussing about now is that GCC and LLVM want to remove some obsolete constructs from gnu17 that were removed in C99 but kept as part of the "GNU extensions" for backwards compatibility reasons. I don't think any features were removed from C11/17 so hence the discussion revolves around features that C99 prohibited from the language.

As I understand it.

GCC wants to remove C89 features from their source code with version 14, to lessen maintance cost no longer need to code new cpu features for C89 and remove the code that parses source code the C89 style, so the old codepath will be gone for good.

Now what happens if you want to compile a project that uses C89 style with gcc 14, it simply fails with an error you can´t compile it anymore.

But Fedora wants to keep the toolchain up to date, so they want gcc 14 in Fedora 40, but now projects fail to build, could be some small basic libs or even things like gtk gnome X where ever some old header files or code files use the old C89 style, the min req is C99.

Now they have to start building hundreds of projects with -std=C99 -werror and go hunting for those leftovers that makes the build fail and then get the patches upstreamed so the code for common used fedora packages is C99 ready and builds when they start their fedora 40 alphas and start useing gcc 14, so it´s quite a massive thing.

And it will make the hole gnu codebase better for all distributions once those efforts get upstream, cause you get rid of alot of old rot and nasty warnings etc.

[marios]

"Strict C99". An almost a quarter of a century old standard, nobody had the guts to pull the trigger on until now. I hope people that think we don't need Rust, that C and C++ are perfectly fine are reading this.

0. We might or might not need Rust. We certainly don't need Rust crusaders. Just mocking C and C++ and making yourselves look like a cult does nothing good to anything, not even to Rust. Except if you are a indeed cult, in which case none will expect anything else.
1. Before mocking a standard as a "quarter of a century old", maybe you should think, why the language of your choice has no official standard (or specification if those 2 are different). Nobody sane would like a language, the de facto standard of which is the behavior of a specific compiler.

[bug77]

0. We might or might not need Rust. We certainly don't need Rust crusaders. Just mocking C and C++ and making yourselves look like a cult does nothing good to anything, not even to Rust. Except if you are a indeed cult, in which case none will expect anything else.

I am not mocking anything. I routinely admit the world literally stands on the shoulders of C and C++. I also admit Rust has a chance to improve on both C and C++. It will take over a decade, best case scenario, but there is potential to improve the status quo.

1. Before mocking a standard as a "quarter of a century old", maybe you should think, why the language of your choice has no official standard (or specification if those 2 are different). Nobody sane would like a language, the de facto standard of which is the behavior of a specific compiler.

C got its first standard in 1989. It was 17 years old by then. Rust is still too moving a target to standardize just yet. Having just one compiler to worry about allows you to move fast. Much faster than you can when you have a bunch of other implementations to take care of. This may change, but for the time being, I don't see lack of a standard hindering Rust in any way.