Guess what, if you install a 10 year old version rust none of your code would not compile at all. Your logic is so flawed its hard to believe you are being serious. If anything it's impressive that a 10 year old C compiler worked most of the time when most other languages are not stable on these timescales.
It's not easy, even in a few hundred lines I had to remove many conveniences to go that far back, but it's very legible. The compiler has my back, I'm never confused about whose fault it is.
Rust is young, but I don't expect this to be any different in 2030.
Rust was not stable in 2012 yet.
I do agree with your overall point though.
If you write the compiler in Rust it could still happen. Rust code (that compiles) has less bugs than the corresponding C but not zero bugs.
It doesn't sound like you went overboard, it sounds like a good project. Maybe you should have written it in Perl 5.001 though.
Even with Valgrind it can be tough to distinguish whether your output code is wrong because of a bug in the compiler or because your code was just wrong. There was a change to GCC a few years back that introduced security holes into the FreeBSD and NetBSD kernel because it just threw away code that would only be invoked in "undefined behavior" scenarios. Signed integer overflow I think.
He said if he had used rust - I am saying if he had used C when rust was available 1. The bug would have been fixed. 2. He could have used valgrind. Modern C also has something called ubsan, and another thing called frama-C.
These tools may be inferior to what rust has, but ignoring they exist or comparing 10+ year old C with modern rust is a bad faith argument.
However, I also don't think they particularly help you to distinguish a compiler bug from an error in your understanding of the language semantics, although they sure do help a lot with everyday errors.
With respect to questions of inferiority or superiority, keep in mind that Valgrind and UBSan are only dynamic checkers; they don't help at all with errors that don't occur in your testing. Frama-C is a static checker more similar to Rust's capabilities, but much more limited, but also with cscope-like abilities for reverse-engineering existing source bases.
The great advantage these three tools (and ASan) have is that you don't have to rewrite your C in Rust in order to use them.
I agree and I disagree ;)
I agree because having a type system that directly provides the guarantee that whole classes of runtime error cannot happen provides fast feedback during development at a low cost.
I disagree because even in a press button (+ tuning) approach, you can prove things with Frama-C that the Rust compiler cannot prove (reason why there is runtime bound-checking, implementation defined behavior for integer overflow and so on in Rust). But also because you can prove much more advance properties than "just" absence of runtime errors.
https://frama-c.com/fc-plugins/mthread.html
(And by the way since it is not done by typing it is hard to use on legacy code)
The Rio Receiver came out 21 years ago. That was a Linux box sold as a consumer electronics stereo component; it grabbed MP3s over Ethernet to play them. I don't remember how much it cost but it was less than US$300.
But apparently the original author tried using asan? That seems like an inconsistency in the story.
GCC started having parts written in C++ 12 years ago: https://lwn.net/Articles/542457/