Hacker News Reader

Comment by royjacobs | Hacker News Reader

One thing that puzzles is me is why some of these checks aren't just part of the warnings that a compiler emits. I get that you wouldn't want to enable them all the time, but usually comparing a variable to itself is not what you want.

View on HN

gcc and clang have been getting better at this recently. For instance if you do an "x == x" comparison for an int x clang will warn "warning: self-comparison always evaluates to true [-Wtautological-compare]".

I completely agree that having these warnings in the compiler is much better than a standalone analysis tool, because they're less likely to be ignored. But I think it may have been a bit of a shift of mindset for the compiler developers to put more effort into warnings and diagnosing dubious code rather than simply being a code generator for correct code.

Lint exists since 1979.

Everything that is outsourced for an external tool, just happens not to be used by the majority.

Clearly the introduction of clang and its sanitizers has changed a bit the mindset, however they are still used by a minority.

As per CppCon 2016, 1% of the audience confirmed they were using some kind of validation tool.

I agree, but my sense is that the number of people and projects willing to fix complaints reported by compiler warnings is larger than the number of people who care enough to run a separate tool over their codebase. This is purely a UI thing -- if the compiler had a -Wlint option that ran lint and integrated its reports into its own warning output it would probably have a similar effect, especially if enabled by default...

To add on this, clang-tidy is a tool specifically for static code analysis. I don't know if it implements all the checks mentioned in the article, but it is quite powerful, being able to detect eg. array overruns through several layers of function calls and ifs.

You're right, but just a fun edge-case to think about (in JS):

  NaN === NaN // -> false

This check is sometimes used to check if a number is NaN.

Better to use `Number.isNaN()`

Sure, and there are cases where you may been reading from some volatile register or something. But that's why I mentioned that this is usually what you want, not always :)

Two main reasons: Many warnings that a static analyzer will emit are quite costly to detect, so the compilation would get slower. And since compilation speed is an important benchmark (if not the most important), one would usually not sacrifice this for some warning. Also, people usually do not accept false-positives in compiler warnings. Static analyzers often have heuristics to detect typos like these:

   a.x = x;
   a.y = y;
   a.y = z; <==

But those heuristics will usually also emit false-positives. This is why pretty much all static analyzers have an easy way to suppress warnings for a certain line (usually through a "magic comment"), but suppressing compiler warnings for a single line is much more cumbersome, since it has to be done through the preprocessor.

That is why it should at very least, be turned on the CI server.

Reply on news.ycombinator.com