3 ms·
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 al
by 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 agoTo 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 agoLint 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 agoI 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...