4 ms·
it might not be all bugs, but 70% of all found bugs is still a lot of bugs that were completely preventable with better language choice.
by adgjlsfhk1 5y ago
it might not be all bugs, but 70% of all found bugs is still a lot of bugs that were completely preventable with better language choice.
- marginalia_nu 5y agoI'm not convinced this statistic is saying more than that these bugs are easily identifiable. There is a lot of tooling for identifying memory errors, and virtually none that could identify something like log4shell.
- adgjlsfhk1 5y agothey are more easily identifiable, but they are also very simple. when writing C, you probably write a potential memory safety bug roughly every 100 lines. Even if you detect 99% with automated tooling that's still a pretty sizable attack surface.
- marginalia_nu 5y ago> probably write a potential memory safety bug roughly every 100 line If that is what your C code looks like, then yeah, you should probably not be writing C code.
- adgjlsfhk1 5y agoevery array access and string comparison is a potential vulnerability in C. I'm not saying that in practice, all of them will be vulnerable, just that every one of those is a place where you could miss a check and end up with a memory bug.
- marginalia_nu 5y agoThat's kind of a disingenuous way to reason about it. You absolutely can bounds check your memory accesses in C, and bounds-checked accesses are as safe in C as they are in any other language.
- adgjlsfhk1 5y agothe point isn't that it's impossible to write C that's safe, it's that doing so requires 100% success rate of a human implementing something correctly. furthermore, the main cases where C can get a performance benefit over safer languages are where there is a complicated invariant that ensures safety. the problem is that these are incredibly easy to break during refactoring, or when a different dev modifies the code later. compilers are much better then humans at verifying that code is correct.