4 ms·

Compilers should really implement such thing... Can't it be a GCC extension or something?

by jokoon 5y ago

pabs3 5y ago
There is the GCC static analyzer and the LLVM equivalent: https://lwn.net/Articles/869880/ https://lwn.net/Articles/869880/ https://gcc.gnu.org/onlinedocs/gccint/Static-Analyzer.html https://gcc.gnu.org/onlinedocs/gccint/Static-Analyzer.html https://gcc.gnu.org/wiki/DavidMalcolm/StaticAnalyzer https://gcc.gnu.org/wiki/DavidMalcolm/StaticAnalyzer https://developers.redhat.com/blog/2021/01/28/static-analysis-updates-in-gcc-11/ https://developers.redhat.com/blog/2021/01/28/static-analysi... https://clang-analyzer.llvm.org/scan-build.html https://clang-analyzer.llvm.org/scan-build.html
- jsteemann 5y ago
  Clang's scan-build supports C++ for a long time already. Regarding gcc/g++, there seems to be support only for C. From https://gcc.gnu.org/wiki/DavidMalcolm/StaticAnalyzer https://gcc.gnu.org/wiki/DavidMalcolm/StaticAnalyzer: > Initial implementation was added in GCC 10; major rewrite occurred in GCC 11. > Only C is currently supported (I hope to support C++ in GCC 13, but it is out-of-scope for GCC 12) Looking forward to seeing C++ support added to it!
  - rwmj 5y ago
    I've found loads of bugs in the C support and David has been very responsive to my bug reports, even substantially reworking how realloc(3) was being handled because of a case we found. (Edit: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99260 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99260 - I must get around to testing his fix since GCC 12 is in Fedora now)
bregma 5y ago
Why? Oh, I understand. There are two kinds of engineers: the lumpers and the dividers. The lumpers like to build one single massive engine that does everything, and the dividers prefer many small engines that do one thing, do it very well, and can be composed with other small engines in new and innovative ways and provide redundancy, maintainability, and scalability. Obviously I count myself in the latter group. So the question for me is, what possible advantage would consolidating everything into one tool give me? Consider that I'm a software development toolchain engineer by trade in your reply.
- pm215 5y ago
  The major benefit to "tool is part of the compiler" is that vastly more people will use it and maybe fix the errors. There's a Google paper from 2018 (https://m-cacm.acm.org/magazines/2018/4/226371-lessons-from-building-static-analysis-tools-at-google/fulltext https://m-cacm.acm.org/magazines/2018/4/226371-lessons-from-...) about their experience with static analysis tools, and what they found was that the better the analysis was integrated with the existing developer workflow and the earlier the issues were noted, the more likely they were to actually be fixed. So "existing compiler reports the errors" is better than "tooling reports the errors as comments in the existing code review system" is better than "tooling files bugs in the existing bug tracking system after new code is already committed" is better than "tooling has its own separate dashboard that nobody looks at". I don't care whether under the hood the implementation is fully part of one big "compiler" engine or not, in the same way I don't care that when I run 'gcc' it's really running a compiler, assembler and linker which are all self-contained programs -- I do care that when I say "build my code" in the usual way that that is when analysis happens.
  - htfy96 5y ago
    the downside of this is that companies with locked compiler versions won't be able to use the static analysis tool. Up-to-date compiler versions, according to my observation, is more like a privilege of BigTech and startups. Tons of firms are still using the bundled compiler in RHEL and only upgrade every 3-5 years, though in this case the off-tree decision more likely came from the intent of bypassing compiler repo code reviews for faster iteration (very typical at BigTech when you need KR every quarter)
    - secondcoming 5y ago
      They can continue to use their existing analysis tools, no?
    - pjmlp 5y ago
      Lint exists since 1979, they certainly have newer toolchains.
- 5y ago
rwmj 5y ago
This tool includes a patched clang FWIW.

Compilers should really implement such thing... Can't it be a GCC extension or something?

by jokoon 5y ago

Compilers should really implement such thing... Can't it be a GCC extension or something?

There is the GCC static analyzer and the LLVM equivalent: https://lwn.net/Articles/869880/ https://lwn.net/Articles/869880/ https://gcc.gnu.org/onlinedocs/gccint/Static-Analyzer.html https://gcc.gnu.org/onlinedocs/gccint/Static-Analyzer.html https://gcc.gnu.org/wiki/DavidMalcolm/StaticAnalyzer https://gcc.gnu.org/wiki/DavidMalcolm/StaticAnalyzer https://developers.redhat.com/blog/2021/01/28/static-analysis-updates-in-gcc-11/ https://developers.redhat.com/blog/2021/01/28/static-analysi... https://clang-analyzer.llvm.org/scan-build.html https://clang-analyzer.llvm.org/scan-build.html

jsteemann 5y ago
Clang's scan-build supports C++ for a long time already. Regarding gcc/g++, there seems to be support only for C. From https://gcc.gnu.org/wiki/DavidMalcolm/StaticAnalyzer https://gcc.gnu.org/wiki/DavidMalcolm/StaticAnalyzer: > Initial implementation was added in GCC 10; major rewrite occurred in GCC 11. > Only C is currently supported (I hope to support C++ in GCC 13, but it is out-of-scope for GCC 12) Looking forward to seeing C++ support added to it!
- rwmj 5y ago
  I've found loads of bugs in the C support and David has been very responsive to my bug reports, even substantially reworking how realloc(3) was being handled because of a case we found. (Edit: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99260 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99260 - I must get around to testing his fix since GCC 12 is in Fedora now)

bregma 5y ago

Why? Oh, I understand. There are two kinds of engineers: the lumpers and the dividers. The lumpers like to build one single massive engine that does everything, and the dividers prefer many small engines that do one thing, do it very well, and can be composed with other small engines in new and innovative ways and provide redundancy, maintainability, and scalability. Obviously I count myself in the latter group. So the question for me is, what possible advantage would consolidating everything into one tool give me? Consider that I'm a software development toolchain engineer by trade in your reply.

pm215 5y ago
The major benefit to "tool is part of the compiler" is that vastly more people will use it and maybe fix the errors. There's a Google paper from 2018 (https://m-cacm.acm.org/magazines/2018/4/226371-lessons-from-building-static-analysis-tools-at-google/fulltext https://m-cacm.acm.org/magazines/2018/4/226371-lessons-from-...) about their experience with static analysis tools, and what they found was that the better the analysis was integrated with the existing developer workflow and the earlier the issues were noted, the more likely they were to actually be fixed. So "existing compiler reports the errors" is better than "tooling reports the errors as comments in the existing code review system" is better than "tooling files bugs in the existing bug tracking system after new code is already committed" is better than "tooling has its own separate dashboard that nobody looks at". I don't care whether under the hood the implementation is fully part of one big "compiler" engine or not, in the same way I don't care that when I run 'gcc' it's really running a compiler, assembler and linker which are all self-contained programs -- I do care that when I say "build my code" in the usual way that that is when analysis happens.
- htfy96 5y ago
  the downside of this is that companies with locked compiler versions won't be able to use the static analysis tool. Up-to-date compiler versions, according to my observation, is more like a privilege of BigTech and startups. Tons of firms are still using the bundled compiler in RHEL and only upgrade every 3-5 years, though in this case the off-tree decision more likely came from the intent of bypassing compiler repo code reviews for faster iteration (very typical at BigTech when you need KR every quarter)
  - secondcoming 5y ago
    They can continue to use their existing analysis tools, no?
  - pjmlp 5y ago
    Lint exists since 1979, they certainly have newer toolchains.
5y ago

rwmj 5y ago

This tool includes a patched clang FWIW.