Hacker News new | ask | show | jobs
by adgjlsfhk1 681 days ago
The key point is that no matter how you write your C code, for anyone else that wants to verify a lack of memory safety problems, they need to read every single line to determine which ones do the low level unsafe bits.
1 comments

I understand this, but the importance of this is highly exaggerated. How in the world does it make sense to only audit for memory safety? There plenty of other safety and security issues. Only if you pretend that memory safety is all that matters, you can then claim a fundamental example that you only need to look at "unsafe blocks" and nothing else. Now, you can say that with limited time we can at least more easily ensure memory safety by reviewing "unsafe blocks" carefully and neglecting other problems. And this is true and I agree that this is an advantage, but the overall improvement for safety and security is incremental in reducing risk and not fundamental.
This isn't only about formal audits. Memory corruption and UB type bugs are also some of the hardest to debug since they may not reproduce in debug builds.
With sanitizers and valgrind I do not quite see this, in my experience subtle logic in overly complicated logic bugs much harder to debug.