Hacker News Reader

Comment by jonhohle | Hacker News Reader

Static analysis tools should be the standard part of any build process, but especially with C/C++.

I’ve mentioned before here, but when I found a reasonable number of bugs in critical library used throughout one of the FAANGs written by their most senior and brilliant engineers by running a fizzier on it for a few hours, my opinion of those languages changed.

Integrating Valgrind and Clang’s checker, and running AFL for many CPU years was critical in unearthing some really funky crashes, hangs, overflows. Without those tools it’s not clear that those bugs would have been fixed. In fact, one of them affected me a few months prior and AFL helped uncover the codepath that was failing.

View on HN

Every language has some expression weaknesses, and C/C++'s are such that the languages make static analysis tools mandatory for correct code (much like Python makes every-line-is-executed unit tests mandatory for correct code).

I don’t think that this bugginess is an inherent property of these languages, because there are other practices that could lead to reduction in total bug count and severity, apart from integrating additional tooling.

Out of curiosity, how many bugs you found by using these tools could have been avoided by using a “watertight” memory management system [0], with strong decoupling of pointer and object lifetimes?

[0] https://floooh.github.io/2018/06/17/handles-vs-pointers.html

I'm curious who the target demographic is for this, people who think they need bare metal performance in a language that gives them access to bare pointers, know that most humans aren't capable of following Uncle Ben's adage[1], and then voluntarily give it up while insisting they need it?

I think almost any JITed memory safe language will be faster than using handles for all object access. At least Java, .NET, JS, etc under the hood can avoid "double dispatch" of memory access. And you can use things like arenas to ensure same objects are allocated adjacently, etc.

[1] With great power comes great responsibility

The solution presented solves "memory corruption" from the point of not having undefined behavior, but it doesn't really protect against "I accidentally created an index that has nothing to do with memory I manage, but is still 'in bounds' to the code that handles lookup".

Reply on news.ycombinator.com