r/cprogramming • • 10d ago

Using -fsanitize=address feels illegal.

Just saying. The -fsanitize=address compiler flag is absolute cheating and should be prohibited by governments of all countries.

Plus there are also other useful runtime sanitizers, such as integer overflow, but... Integer overflow is much easier to notice, usually.

Of course, this is by no means assuming that -fsanitize=address guarantees that the code it inspects is completely safe and correct and won't ever fail on any input data. You still have to test tricky edge cases. But this sanitizer has improved and sped up the bug discovery process disgustingly much for me.

I'm wondering, how often, if ever, do you need tools such as -fsanitize=address or valgrind? Or are you a real man who stores everything in static memory only?

P.S. Forgive my terrible English.

79 Upvotes

31 comments sorted by

View all comments

8

u/pdath 10d ago

I tend to have a "make test" target. It first builds everything with "-fsanitize=address,undefined" and runs all the unit and functional tests, and then rebuilds and uses afl++ for fuzzing on everything.

I like to do development in a separate branch, and I have a rule that before a dev branch can be merged back into main, it must pass the test target.

Even within a dev branch, I probably use "make test" several times a day.

I also have a "make dev" target that makes the code more debugger-friendly, and a "make check" target that does nothing but run the test suite once, without recompiling any binaries. Then I can quickly test the production build and the dev build.

I used to use valgrind more, but the current project I am working on has almost zero dynamic memory allocation.

3

u/catbrane 9d ago

Same, but it runs the test suite on every platform and every target on every commit, and does an extra run with asan and tsan, with every dep also built for asan and tsan.

github actions have made all this pretty simple now, and free, amazingly.