3 ms·

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

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.

cprecioso 8y ago
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.
- andreareina 8y ago
  Better to use `Number.isNaN()`
- royjacobs 8y ago
  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 :)
pm215 8y ago
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.
- CapacitorSet 8y ago
  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.
- pjmlp 8y ago
  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.
  - pm215 8y ago
    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...
deng 8y ago
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.
- pjmlp 8y ago
  That is why it should at very least, be turned on the CI server.

cprecioso 8y ago

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.

andreareina 8y ago
Better to use `Number.isNaN()`
royjacobs 8y ago
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 :)

pm215 8y ago

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.

CapacitorSet 8y ago
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.
pjmlp 8y ago
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.
- pm215 8y ago
  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...

deng 8y ago

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.

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