Hacker News new | past | comments | ask | show | jobs | submit
I used to think writing safe code in C/C++ was a matter of skill. However, after finding more than a few issues with AFL at a FAANG in code written by engineers with the highest engineering title, I changed my mind. Incredible tool.
It is a matter of skill to a large extent, though. A skilled programmer will write fewer bugs on average than an unskilled one. They'll know the patterns to avoid and have a higher bar for quality. Nobody can write 100% bug-free code, independent of programming language. Also, job title might correlate with skill but it doesn't rule out incompetence at the highest levels.
loading story #50330805
loading story #50331821
loading story #50330651
loading story #50330427
I think that good use of static analysis and fuzz testing is a part of the skill to detail-oriented programming languages.
>I used to think writing safe code in C/C++ was a matter of skill.

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.

loading story #50331228
Has there ever existed a C or C++ codebase of significant size that hasn't had exploitable memory corruption issues? I don't think we can keep saying it's a question of the dev's passion or skill or whatever, if no dev has ever managed to do it.

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...

An example that comes to mind is postfix (the SMTP daemon). It hasn't had zero memory safety issues, but nearly so. Certainly an abnormally low amount given the size/complexity of the project and the number of eyes on it.

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.

loading story #50333990
{"deleted":true,"id":50332327,"parent":50330106,"time":1793585950,"type":"comment"}
{"dead":true,"deleted":true,"id":50332328,"parent":50330106,"time":1793585950,"type":"comment"}