[HN Gopher] IKOS: Static analyzer for C/C++ based on the theory ...
___________________________________________________________________
IKOS: Static analyzer for C/C++ based on the theory of Abstract
Interpretation
Author : ingve
Score : 52 points
Date : 2022-04-20 17:48 UTC (5 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| yaantc wrote:
| Another open source alternative is CodeChecker [1] with the Clang
| static analyzer [2]. Make sure the Clang toolchain has been
| compiled with Z3 [3] support for better results (it's the case in
| Debian stable), particularly for code doing bit operations. It
| supports cross files analysis ("cross translation units" or CTU),
| which last time I checked was not the case for IKOS and helps
| improve diagnostics.
|
| It's not completely turn key if you use it for a cross compiled
| code base, but once set-up I prefer it to another professional
| tool: much less false alarms. Although it's good to have both,
| each one found issues not seen by the other. [1]
| https://github.com/Ericsson/codechecker [2] https://clang-
| analyzer.llvm.org/ [3] https://github.com/Z3Prover/z3
| marcodiego wrote:
| Time to update
| https://en.wikipedia.org/wiki/List_of_tools_for_static_code_...
| einpoklum wrote:
| > "based on the theory of Abstract Interpretation."
|
| I don't know about you all, but I get a bit scared when people
| tell they're basing what they're doing to me on some kind of
| abstract interpretations :-(
| marcodiego wrote:
| It impresses that age has not meant better tooling for C/C++ when
| compared with more modern languages.
|
| I really envy productivity people using more "dynamic" languages
| have had over C/C++ developers just because of tooling. Of
| course, each language is like a tool tailored for a more adequate
| domain and I'm sure better tooling wouldn't magically fix all of
| old languages' traps. Nevertheless I miss it.
| fluoridation wrote:
| I don't agree at all. For example, some of the best debuggers
| I've used have been for C/++. As far as I understand it, even
| after years, debugging in Node.js still hasn't progressed
| beyond the level of printf() debugging.
|
| Also, by their very nature, dynamic languages offer less
| information at development time about things such as types and
| function signatures, so very often IDEs can't even tell you the
| type associated with a name by hovering over it.
| mumphster wrote:
| I think you understand wrong.
| https://nodejs.org/api/debugger.html Combined with chrome dev
| tools or an ide of your choice has been some of the best
| tooling I've used in any programming language
| jhgb wrote:
| Common Lisp implementations allowed you to change your
| program's code while debugging decades ago. Microsoft added
| bare minimum of similar functionality like fifteen years ago
| or so, if I remember correctly. I'm not even sure they've
| caught up on class redefinition and instance upgrade at
| runtime yet, which has been supported in CL since the 1980s.
| astrange wrote:
| Apple platforms used to have that ("zero-link") and removed
| it quickly because nobody actually liked it. I think this
| and Lisp/Smalltalk's image model is actually mistaken.
|
| It goes against the principle of "crash-only recovery" to
| try to recover from a bad state instead of being able to
| start over from the beginning.
| The_rationalist wrote:
| jcelerier wrote:
| Could you detail what exact tooling you are talking about ?
|
| Like, this static analyzer looks interesting but 5 years ago
| clang --analyze had no trouble producing me a nice html
| indicating the 27 steps across 6 functions that lead to a
| pointer being dereferenced after being deleted. Tooling is
| there but it seems that pretty much no one is aware of it - see
| e.g. this: https://github.com/cpp-best-
| practices/cppbestpractices/blob/... or this:
| https://github.com/fffaraz/awesome-cpp for a quick look at what
| exists (and both are very non-exhaustive).
| marcodiego wrote:
| Yes, the tools maybe there, but for more modern languages,
| they didn't needed so long for the same tools to appear.
| jcelerier wrote:
| but most of these tools are, like, 10+ years old. Intel
| VTune, Coverity and KCacheGrind were already a thing in
| 2003. PC-LINT dates back to 1985. Of course languages more
| recent don't have to reinvent the ideas that have been
| developed for these older languages, it would be like
| saying that the first automaker sucked because the second
| automaker took less time at producing a vehicle.
| marcodiego wrote:
| I remember people using eclipse and having orthography
| correction on comments, fixmes, "instant" reanalysis
| whenever the code was changed, automatic creation of
| accessory methods... things like that. I don't remember
| the same features were as popular among C/C++ developers
| at the time.
|
| Maybe my feeling is wrong, but I always had a feeling
| that more "modern" more "dynamic" languages implemented
| development tools faster or even before the same features
| became available and popular for C/C++.
| fluoridation wrote:
| C++ is much more difficult to parse than Java, so
| refactoring is a big ask. If your renaming tool can miss
| some usages it's worse than nothing. IMO C++ also has
| always had less boilerplate than Java, so boilerplate
| generators were less useful. C++ also has other typing-
| saving tools, such as the preprocessor (we can argue
| about whether it's a good tool, but it can certainly save
| typing).
| pjmlp wrote:
| Not using C++ Builder, Visual Studio or Clion?
|
| I should also note there used to exist some great tooling that
| failed in the market, because they were too soon with heavy
| hardware requirements.
|
| Energize C++ and Visual Age for C++ version 4.
| marcodiego wrote:
| I wouldn't consider C++ Builder as C++. Have not used it in
| ages, but last time I used it, it was not C++. Anyway, that's
| is not exactly what I was talking about. I think even the
| tools you listed lacked years behind useful features that
| eclipse and netbeans implemented for java like refactoring.
|
| I'm glad there are good front-ends to the llvm language
| server though and that static analyzers are slowly improving
| and becoming more popular even to the sporadic hobbyist.
| pjmlp wrote:
| C++ Builder compiles C++, thus it is C++.
|
| I will never understand why clang and GCC extensions are
| considered part of C or C++, while other compilers aren't.
|
| Refactoring exists for 20 years in Visual Studio with
| plugins like Visual Assist.
|
| The tools I mentioned as ahead of their time allowed for a
| Lisp Machines or Smalltalk like experience for C++,
| respectively.
| marcodiego wrote:
| > C++ Builder compiles C++, thus it is C++.
|
| By your definition.
|
| > I will never understand why clang and GCC extensions
| are considered part of C or C++, while other compilers
| aren't.
|
| Didn't say so.
|
| > Refactoring exists for 20 years in Visual Studio with
| plugins like Visual Assist.
|
| That one is new for me. Didn't know it. Would love to
| have it not locked to a single proprietary non multi-
| platform IDE.
|
| > The tools I mentioned as ahead of their time allowed
| for a Lisp Machines or Smalltalk like experience for C++,
| respectively.
|
| And they didn't succeed, become popular and were mostly
| completely unreachable to the sporadic hobbyist.
| jcelerier wrote:
| > Would love to have it not locked to a single
| proprietary non multi-platform IDE.
|
| https://doc.qt.io/qtcreator/creator-editor-quick-
| fixes.html
| marcodiego wrote:
| Nice! Thanks!
| Someone wrote:
| That's because the preprocessor adds too much flexibility
| to make it easy to write such tools.
|
| Once you have #ifdef FOO ...
| #else ... #endif
|
| you have to completely preprocess the compilation unit to
| find out which branch is taken. That means you have to
| interpret the build script (which may do _-DFOO_ , possibly
| only for some compilation targets)
|
| You have to do that even for such simple things as syntax
| coloring. Now, you say "I simply parse both branches, check
| what things they define, somehow merge the two, and we're
| good to go". That won't work, as the not taken branch(es)
| need not contain valid C/C++, and their validity may depend
| on whether other branches are taken.
|
| the preprocessor also has concatenation
| (https://gcc.gnu.org/onlinedocs/cpp/Concatenation.html).
| That makes writing a refactoring tool as good as impossible
| (for example, how do you rename _quit_command_ to
| _commandExit_ in the example on that page?)
|
| Now, lots of code is fairly reasonable in its use of the
| preprocessor, but writing a reliable tool is a lot harder,
| if it's possible at all, than with Java.
| marcodiego wrote:
| Thanks for the reasonable view and explanation.
___________________________________________________________________
(page generated 2022-04-20 23:00 UTC)