undefined | Better HN

0 pointsflohofwoe6y ago0 comments

In my experience both clang ASAN and UBSAN (and TSAN, the thread sanitizer) are very solid tools, IFIR I haven't seen a false positive yet (of course some code may be specifically written to rely on undefined behaviour, but of course that's a mine field).

On the other hand, the clang static analyzer may have a shocking amount of messages when run first on a large existing code base, and some of those warnings can be considered more "opinions" than warnings. It's still makes sense and is very rewarding to make a code base "static analyzer clean".

The runtime sanitizers in comparison are very precise and always pointed to actual "sleeper bugs", it's almost definitely a good idea to use them and take their warnings serious.

But anyway, clang ASAN, UBSAN, TSAN and the static analyzer are all really excellent and important tools for everybody writing C or C++ code.

PS: the reason why those checks are optional is that they increase compilation time (sometimes dramatically, like 10x slower compilation or more), and they add runtime instrumentation code which both increases the executables size and decreases performance dramatically (also 2..10x times or more, although the clang sanitizers are really quite fast compared to other solutions).

0 comments

5 comments · 1 top-level

ryandrake6y ago· 4 in thread

A lot of developers I've worked with don't want to use these tools because they are working with already-awful legacy codebases that will emit screenfuls of (legit) positives when run, and it feels overwhelming. I remember working on some teams where all compiler warnings were turned off because if you turned on even the default ones, you'd get hundreds of thousands of them during the build, and it looked bad. Since nobody had the budget to spend any time cleaning up warnings because "customers don't care about compiler warnings" they would never get fixed. Forget even sanitizers: You wouldn't even get the splash screen displayed before ASAN would barf on you.

The best projects are the ones that start out from day 1 with all the pedantic warnings turned on, warnings-as-errors, static analysis and sanitizers run as part of the automated build and any peep out of them gets treated just like an error would get treated. When you start the project out that way, there isn't that de-motivating initial hump to get over.

rs23296008n16y ago

Kind of opposite mindset here.

Current codebase generates around 3000 casting errors. I doubt I'm the only one with this kind of "history" to deal with AND the application is crashing with memory access errors.

What's my cleanup plan for this? Multiple compilers with every warning enabled on multiple platforms. Even a platform we're not targeting. We've mapped out which files and which lines have the biggest code smell. Now we have a giant map on a 65" tv to guide us.

Why all this attention? We're moving this nightmare from 32 to 64 bits. Parts of it were originally 16bit which have already been updated. Cast errors alone are now signposts to other bad code.

yjftsjthsd-h6y ago

> Why all this attention? We're moving this nightmare from 32 to 64 bits

It helps that you then almost certainly have buy-in and are allowed to treat this as a priority because it's tied to work that the business is willing to prioritize. You're already over the hurdle of "customers don't pay to fix compiler warnings".

1 more reply

pletnes6y ago

Been there done that. One great feature I ran across was that the intel compiler has a #pragma incantation that enables many checks on a per-file basis. This lets you create new code and selectively fix old code without these obvious defects.

zwp6y ago

So does gcc: https://gcc.gnu.org/onlinedocs/gcc/Diagnostic-Pragmas.html

(TIL - thanks!)

j / k navigate · click thread line to collapse