Posted by luu 4 days ago
Writing safe C is a matter of either radically different (much, much slower) process or better tooling or both. Skill is not sufficient.
It's a matter of how many fucks the devs gave about doing quality work. You can find inexperienced people deliver quality work simply because they're passionate and they care (Half-Life was made in part by people with no prior game or coding experience), and you can find supposed rockstars deliver slop because for whatever reason they don't care, they just want to punch in, collect paychecks, then punch out.
FAANG stopped being a benchmark of skill a while ago. It's a skill of griding leetcode and 7 stage interviews to get it, then resting and vesting till you can jump ship to something better or get mass layd off.
It's more a matter of how much management cares about quality, and how much time and how many resources they're willing to devote to it.
And that's a function of how much the quality of the code actually matters in the market.
That's not to say memory corruption issues are the only kind of issues, and rewriting a mature C/C++ codebase into a memory safe language may well introduce more issues than it fixes...
It's also had a pretty 'normal' (read: higher) amount of non-memory related bugs such as SMTP smuggling of filesystem permission TOCTOU, so it's not like its devs are somehow really good at just not writing bugs.
Maybe they have chosen a software architecture that allows them to avoid complicated memory-related logic? I genuinely don't know, would love to hear from a postfix developer.
Also I think it is noteworthy that memory-safety issues are really well-defined and can automatically be found using sanitizers and fuzzers or verification tools. This is not the case for many other correctness issues and once memory safety issues are fixed this will remain as a major problem for all code.
I had been playing with and building fuzzers long before AFL, but its release and its ability to explore the code space in a smart way fundamentally changed the game. Never once have I improved a codebase so it could be fuzzed and didn't get a payoff of it finding bugs.
And the field is relatively young. Like the other year built a fuzzer with a transformer model as the internal learning engine and other cool stuff like https://antithesis.com
I know fuzzing has been around forever, but it is still surprising how many engineers I encounter who have never used one. I hate fixing bugs and love tools that just find bugs and gave me exact reproducible cases. It was nice to see GoLang get a built in fuzzer to try to help it become more mainstream.
And these days with AI where you need ways it both can't gamify (a unit test that simply returns 'pass') as well as automatic ways to eval generate code fuzzing is a great fit. And not to mention that it is cheaper to fuzz all night than continuously burn tokens looking for ways to crash the code.