Modern C for Fedora (and the world)

That's what I did with a code base. Just worked through the codebase adding -W3 to each module in turn, and cleared all the errors. It took time, but the quality of the code base shot up, and loads of unexplained errors just disappeared :-)

Cheers,
Wol

Yes, that is true.

Type inference works well in Rust due to its strict type system.
But a subset of Rust's type inference will probably work well in C.

I would agree with this. The main concern I can think of is how C handles numeric conversions. They are messy, complicated, and I always have to look them up.[1] They can mostly be summarized as "promote everything to the narrowest type that can represent all values of both argument types, and if an integer, is at least as wide as int," but that summary is wrong (float usually *can't* represent all values of int, but C will just promote int to float anyway). Throwing type inference on top of that mess is probably just going to make things worse.

By contrast, Rust has no such logic. If you add i32 + i16, or any other situation where the types do not match, you just get a flat compiler error.

I do wish Rust would let me write this:

let x: i32 = 1;
let y: i16 = 2;
let z: i32 = x + y.into(); // Compiler error!

(Presumably this is because you can also add i32 + &i32, and the compiler isn't quite smart enough to rule out that override.)

The compiler suggests writing this abomination, which does work:

let z: i32 = x + <i16 as Into<i32>>::into(y);

But at least you can write this:

let x: i32 = 1;
let y: i16 = 2;
let y32: i32 = y.into();
let z: i32 = x + y32;

[1]: https://en.cppreference.com/w/c/language/conversion

I disagree with this, assuming that "safe" means "cannot cause UB outside of an unsafe block." A safe version of C needs at least the following:

* Lifetimes and borrow checking, which implies a type annotation similar to generics.
* Type inference, or else you have to write lifetime annotations everywhere.
* Box<T> or something equivalent to Box<T>, or else you can't put big objects on the heap and move their ownership around.
* Arc<RwLock<T>> or some equivalent, or else you have no reasonable escape hatch from the borrow checker (other than unsafe blocks).
* Rc<RefCell<T>> or some equivalent, or else you have to use the multithreaded escape hatch even in single-threaded code.
* And then there are many other optimizations such as using Mutex<T> instead of RwLock<T>, or OnceCell<T> instead of RefCell<T>. All of these have valid equivalents in C, and should be possible to represent in our hypothesized "safe C" (without needing more than a minimal amount of unsafe, preferably buried somewhere in the stdlib so that "regular" code can be safe).

I just don't see how you provide all of that flexibility without doing monomorphization, at which point you're already 80% of the way to reinventing Rust.

What I'm really getting at is, what is K&R C, from the compiler author's perspective? How do you know if a given compiler is a "valid" implementation of K&R? How do you know what optimizations are permitted? If the answer is "no optimizations are allowed, because there's no C abstract machine yet, so everything must be translated 1:1," then how do you decide what constitutes "1:1" output? Even the modern C standard does not define such a notion, and users would probably like to have some optimizations anyway.

I don't think there's any sensible answer to those questions that doesn't ultimately look like C89 with a bunch of -f options to enable K&R constructs, which is why there's no -std=kr option. The second edition explicitly acknowledges this limitation in the preface, and directs compiler authors to the C standard.

However:

Did any actual C standard parse it as the latter?

If yes, then my point stands, meaning that if someone invokes a C compiler and explicitly tells it to use whatever old C standard that was, then that's the way it should be parsed. Does this cause a security issue? No! Because you have explicitly specify that.

If no, then the point is moot, because if it's not specified behavior then I'd say the compiler is free to change its behavior as it pleases.

So basically how MSWord operated all those decades... :-p

The work mentioned in the article is good work! Opting in to new checks that disallow bad patterns, and then updating code to fix all the errors, is almost always a good thing to do.

My comment wasn't responding to the article. My comment was responding to the statement "If you want this legacy code keep compiling, please use a 30 years old compiler."

> Also, you seem to dismiss backwards compatibility in other languages a bit quickly.

"Backwards compatibility" these days usually tends to mean "we'll make your code spam log files with warnings for a year and then stop working altogether until you fix it".

Real backwards compatibility means that the intended and documented behavior of an old version of something will be kept (at least, once any necessary opt-ins have been performed), even if it's deemed to have some flaws.

I'm not calling for _exact_ behavior, such as bugs, to be retained - just behavior that is documented and intended (or at least was intended at the time it was documented).

I'm not concerned about legacy code that wasn't valid in the first place. If someone's relying on a behavior that's undocumented, or indeed where the documentation says it shouldn't be relied on, there's no need to keep that behavior at all.

> if Q is valid according to standard S, then there are many Rs that have the same behaviour on the real machine as program Q does on standard S's abstract machine. [...] I'd still like compiler P to be permitted to rearrange such that all delay slots do useful work if I compile program Q again.

OK, I wasn't quite specific enough on this note. It had occurred to me that someone might make the optimisation argument but I didn't want to get lost in the details of that. :) What I meant by "executable R" was "an executable that does what it's supposed to according to the requested standard and any relevant compiler flags that affect behavior". So if some compiler provides a way to explicitly ask for a deterministic build then yes, it should always generate the exact same output bit-for-bit, if the same input is given, no matter how many updates to the compiler there have been. However, that's if you explicitly request a deterministic build. If you just specify certain compile flags that permit a range of possible behaviors, then of course the output should be allowed to vary within the permitted behaviors, such as allowing new optimisations.

My key point was that language maintainers should make provisions for people to be able to compile old code with new compiler versions without undue effort, so that you can use a single compiler version (preferably installed systemwide) to compile a wide range of code, rather than having to have lots of different compiler versions installed. The corollary is that any given source code would work on a wide range of compiler versions. (And I would call on library maintainers to do similar, so that projects that depend on them will work on a wide range of library versions.)

that should be "not _enough_ good reasons"

This scenario is describing a very real problem that folks with existing codebases have to deal with.