I like C as well, but I never kid myself into thinking that discipline and documentation can replace compiler restrictions. I've written large codebases in C, sometimes alone, sometimes in a team, and despite DECADES of experience and meticulous attention to detail, I STILL find the same old memory errors in my own code.
C cannot be made safe because you are not a god.
I mean this is demonstrably untrue: SEL4 is written by mere mortals, in C. It's safer than rust, there are formally verified security guarantees that include and go beyond the memory safety of rust.
It is the case though that c is an incredibly shitty language to do this sort of static analysis on because for example it's easy to do shenanigans like lexical macros that make the static analyzers job much much harder.
But fine. With that kind of dishonesty I could claim that the Linux kernel is written in nothing: I have compiled it and deleted the source code. Look ma, it’s no-code kernel.
[1] Kind of a bummer though that you cannot change any of the C code any more now that the verification code is gone.
Funky macros can still make static analysis more complex by introducing layer(s) of indirection of course.
But that's not a safe language; that's a safe work. ANY programming work - regardless of language - can be made safe via such expensive means, which puts this square into the space of "argument ad absurdum". You could argue that brainfuck or assembler can be made safe via these means, but everyone would rightly ridicule you for it.
If you used something else, you'd need to trust a lot more code.
There's CakeML, which is a formally verified subset of Standard ML [0]
Oh god yes. That should be tattooed on everyone who thinks otherwise. “Ha! Unlike all those other people, who are clearly not as attentive as myself, _I_ never make this type of mistake.”
For instance, I worked in a company that rolled its own coroutines in a way very similar to how they work in Go on top of many other things they did to the language runtime. Valgrind couldn't "understand" what was happening in that runtime at all and if you tried to run it would spew millions of warnings (similar problem you'd have if you used Bohem GC with your C program).
There was a way to "teach" Valgrind to understand what was going on in that runtime, but and even though we tried, at some point we realized that it would take too much effort to do so.
I'd bet that OPs home-made alloca() would have a similar effect on Valgrind too.
I was only trying to defend the article author from the accusation of hubris. If all of these tools are indeed used until they show no errors at all, not even false positives (as the article claims), and if the test suite used to run them is non-trivial, then they are likely far more secure than a typical program written in Rust or even something like Go or C# or Java (which all allow and internally use raw pointer manipulation for things like interop).
Fuzzing wasn't mentioned in the article but the author does at least to some extended in their project, from what I could tell at a glance.
I fuzz religiously. I use it to generate lots of my test suite. I love fuzzing.
I've added a note about it to the post.
Fuzzers frequently also use instrumentation to try to figure out inputs that will hit more code paths in a more intelligent manner.
Not a perfect test suite, but the one for my bc [1] is pretty good.
People arguing that "you can not ever write safe C" might also come to the conclusion that one "unsafe" somewhere in your Rust code potentially means that the whole code base is immediately at the same level of implicit memory safety as C.
No, the forced use of "unsafe" in Rust for some kinds of safety mechanisms to be disabled makes the code to audit easier to locate and reason about.
IF the code in the "unsafe" block does not actually isolate the "unsafe"-ness THEN conclusions can be drawn about the rest of the code.
Contrast that to C where the code introducing unsafeness, UB and unsoundness could be basically anywhere instead of a convenient "rg/grep unsafe" away.
I was just pointing out that, in the case of the particularly diligent OP, he is probably getting an equivalent level of safety - for much more effort though.
Even with just static analysis and some sane coding conventions you can get C on the same safety level of Rust. I see Rust as a huge waste of everybody's time and resources and far too opinionated in many regards.
Either way, x86_64 assembly code is a high level language that gets interpreted by the CPU at runtime, so not sure how relevant it is to anything low level anymore.
> The final reason is the only one that justifies my decision: my code will be rewritten in a memory-safe language. [...] It’s my own language. It’s called Yao.
> This is the only reason I could justify that decision. All of the other reasons above are excuses. This is the real reason.
> You can bet that I do not want to accept liability for a project written in C. It will be rewritten as soon as possible.