4 ms·
Valgrind makes finding leaks so easy in C. Fixing them is harder, but it's usually easy if your design is right. I usually allocate and free in the same functi
by gavinhoward 2y ago
Valgrind makes finding leaks so easy in C.
Fixing them is harder, but it's usually easy if your design is right. I usually allocate and free in the same function unless the function is meant to allocate for the caller. (And then that call is considered allocation in the caller.)
- canucker2016 2y agoIt's the "repro the bug" that's hard... When I worked on static analysis of codebases, the error handling codepath was the most likely source of problems.
- gavinhoward 2y agoYes. To do that, I fuzz like crazy, and every path becomes a test, even if it means a lot of manual work checking each one. That alone exercises tons of error paths. To cover 99% of the rest, I use SQLite's error injection [1] on all tests. Just doing error injection on allocation gets you 90% of the way there. [1]: https://sqlite.org/testing.html#anomaly_testing https://sqlite.org/testing.html#anomaly_testing
- lelanthran 2y ago> I usually allocate and free in the same function unless the function is meant to allocate for the caller. (And then that call is considered allocation in the caller.) Yeah. I do a similar thing in C, but think of it as 'differing level of scopes in the abstraction'[1]. It's pretty easy to visually spot when a scope acquires a resource in $SCOPE::foo() and never releases that resource in the $SCOPE::cleanup(). [1] Like the way code has block scope, function scope, file scope and global scope, a problem domain or an abstraction over the solution (the model) also has varying levels of scope. I've never found this to be a taught thing, however. Modeling the problem domain and any proposed solution is a useful skill before jumping into coding a solution.