I don't remember the original source, but there's some classic frustration with these kinds of tables in academic papers. It's a "look at us, we're good at everything!" selective cherry-picking that omits honest discussion about the limitations of the approach.
Although honestly, the red flag for me was the mention of a "field-sensitive" analysis in C. My experience doing static analysis on C code is that it tends to be so reliant on type punning that field sensitivity ends up kind of not working, at least not without significant effort on detecting and handling type punning in some manner (to say nothing of all of the fun ways people figure out how to encipher pointers).
I think showing with static analysis that existing C code is safe is very hard.
But if you start with modern and cleanly written C and avoid certain techniques (such as type punning) I think it is clear that this can work. Rust fundamentally does nothing else.
> But if you start with modern and cleanly written C
I think I see a flaw in this plan. Everyone is on the curve, but not everyone will be as far along the curve as you or I would like.
The advantage of Rust is that the compiler always enforced all the good practices unless you explicitly opt out, and frankly the error messages that come out of the Rust compiler are a lot more helpful than the ones from the C compiler.
It's hard enough getting folks to treat compiler warnings as errors. Expecting every professional (let alone hobbyist) developer to conform to best practices overall may be expecting too much, and when it comes to security and reliability, we really are all in this together and need to make the best of what we've got.
People who do not want to write safe code will also not use Rust. (Or then use unsafe Rust a lot).
If you want your programmers to write safe code and are in a position to force this, it makes no difference whether you mandate the use of Rust or whether you mandate the use of a safe C subset enforced by a compiler flag.
There is an inherent difference between a language where safety is opt-out (safe by default) and opt-in (unsafe by default).
Ignorance or forgetfulness leads to safety by default in Rust. A single failure of vigilance in C leads to the status quo of unsafety.
This is no small difference. If someone doesn't want all the guardrails of Rust, there are still options like Nim and Zig that provide better options than C for greenfield systems projects today.
Although honestly, the red flag for me was the mention of a "field-sensitive" analysis in C. My experience doing static analysis on C code is that it tends to be so reliant on type punning that field sensitivity ends up kind of not working, at least not without significant effort on detecting and handling type punning in some manner (to say nothing of all of the fun ways people figure out how to encipher pointers).