Read the discussion on HN. A full-thread summary is not available yet.
NASA-SW-VnV
ikos
C++2018–2026
NASA-SW-VnV / ikos
ikos
Static analyzer for C/C++ based on the theory of Abstract Interpretation.
14Distinct people
23Mentions
1Explicit recommenders
3.2KGitHub stars
What to know before exploring
What it is
Static analyzer for C/C++ based on the theory of Abstract Interpretation.
GitHub
Where it is used
No documented product use was verified in the last source check.
What people are saying
Software verification tools based on abstract Interpretation are really good today. If you want free software I recommend IKOS - a is a sound static analyzer for C/C++…
Nokinside used a recommendation phrase. One indexed comment matches. This is a phrase match, not a verdict.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
- static-analysis-engineering/codehawk-c · linked in 2 of the same discussions
Mentioned in the same Hacker News threads. That is not proof they are substitutes.
This week on Hacker News
Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 5:04:57 PM UTC.
Mentions over time
HN mentions by year23 dated mentions
Observed mentions: 2018-12-11 21:25:28 UTC to 2026-01-19 10:51:19 UTC.
* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| 2018 | 2018-01-01 00:00:00 UTC | 2019-01-01 00:00:00 UTC | 2 | 2 | 0 |
| 2019 | 2019-01-01 00:00:00 UTC | 2020-01-01 00:00:00 UTC | 2 | 1 | 1 |
| 2020 | 2020-01-01 00:00:00 UTC | 2021-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2021 | 2021-01-01 00:00:00 UTC | 2022-01-01 00:00:00 UTC | 2 | 0 | 2 |
| 2022 | 2022-01-01 00:00:00 UTC | 2023-01-01 00:00:00 UTC | 4 | 1 | 3 |
| 2023 | 2023-01-01 00:00:00 UTC | 2024-01-01 00:00:00 UTC | 5 | 2 | 3 |
| 2024 | 2024-01-01 00:00:00 UTC | 2025-01-01 00:00:00 UTC | 3 | 1 | 2 |
| 2025 | 2025-01-01 00:00:00 UTC | 2026-01-01 00:00:00 UTC | 2 | 0 | 2 |
| 2026 (partial) | 2026-01-01 00:00:00 UTC | 2027-01-01 00:00:00 UTC | 2 | 1 | 1 |
What Hacker News says
23 sourcesU1u1hcw9nx·Jan 19, 2026
ICOS (from NASA) and Fil-C together make it possible to make more safe code than vanilla Rust.
https://github.com/NASA-SW-VnV/ikos
In Fil-Qt: A Qt Base build with Fil-C experienceIKOS a static analyzer for C/C++ based on the theory of Abstract Interpretation
18 points · Open discussionThat's just start.
The bleeding edge uses abstract interpretation to verify code.
Free from NASA:
IKOS (Inference Kernel for Open Static Analyzers) is a static analyzer for C/C++ based on the theory of Abstract Interpretation. https://github.com/NASA-SW-VnV/ikos
Commercial:
Astrée is a static analyzer for safety-critical software written or generated in C or C++. https://www.absint.com/astree/index.htm
https://www.absint.com/astree/index.htm
abstract interpretation for static analysis and verification:
Good intro Mechanized semantics, fifth lecture
Abstract art:
static analysis by abstract interpretation
https://xavierleroy.org/CdF/2019-2020/5.pdf
Static Analysis and Verification of Aerospace
Software by Abstract Interpretation
https://mine.perso.lip6.fr/publi/article-bertrane-al-fntpl15...
In C ToolingSoftware verification tools based on abstract Interpretation are really good today.
If you want free software I recommend IKOS - a is a sound static analyzer for C/C++ developed at NASA.
Checks:
https://github.com/NASA-SW-VnV/ikos/blob/master/analyzer/REA... Numerical abstract domains:
https://github.com/NASA-SW-VnV/ikos/blob/master/analyzer/REA...
Commercial tool like Astree https://www.absint.com/astree/index.htm if you have money.
In An almost catastrophic OpenZFS bug and the humans that made itSome things, like ZFSOnLinux are already shared publicly. The repository is now the OpenZFS repository and it has made many people's lives better. I know it has made my life easier. The open source development model benefited LLNL, which got a much better code base than they would have developed on their own. :)
There are other things already shared publicly like NASA IKOS:
https://github.com/NASA-SW-VnV/ikos
That one gets far less attention from third parties than it should. If it could be developed into a general purpose sound static analyzer that handles multithreading, it would help to improve many other projects.
In Bill requiring US agencies to share source code with each other becomes lawThere is another option, which is to use a sound static analyzer that can prove the absence of memory safety issues like astree, and fix things that cause it to complain until it stops complaining:
https://www.absint.com/astree/index.htm
For those who think static analyzers cannot do that, notice the word “sound”. This is a different type of static analyzer than the more common ones that do not catch everything.
Sadly, there is no open source option that works across a broad range of software. NASA’s IKOS is open source for example, but it does not support multithreading and some other things that I do not recall offhand, which makes it unable to catch all memory safety bugs in software using the features that it does not support. For now, people who want to use sound static analyzers need to use closed source tools or restrict themselves
Read the rest
to a subset of what C/C++ can do so they can use IKOS:
https://github.com/NASA-SW-VnV/ikos
Ikos: Static analyzer for C/C++ based on the theory of Abstract Interpretation
1 points · Open discussionStatic analyzer IKOS 3.2 Released
1 points · Open discussionNASA's static analyzer IKOS 3.2-rc1 published – Request for testers
2 points · Open discussionI beg to differ: there are a few tools which are comparable.
Frama-C (https://www.frama-c.com) is an open source framework that has, among its analyzers, one based on abstract interpretation (https://www.frama-c.com/fc-plugins/eva.html) that is very similar in spirit to Astree.
MOPSA (https://mopsa.lip6.fr) is another open-source project (albeit more recent, and in a more "academic" stage) that also provides abstract interpretation to analyze C programs for flaws.
NASA also released IKOS (https://github.com/NASA-SW-VnV/ikos), on the same vein.
Of course they lack the polish of a product which costs tens of thousands of euros per license, but they are open source, and their purpose is the same: to ensure code safety via formal methods, in particular abstract interpretation.
It is possible to get these tools to analyze some code and generat
Read the rest
e no complaints, which ensures absence of several kinds of problems, such as memory safety issues.
Then again, it's hard to know exactly how much they differ from Astree, since you need a license to compare them, and I don't even know if you are allowed to publish such comparisons.
I haven't yet. This was my path to Frama-C:
1. Try writing C code that's "obviously safe." Gave up on that pretty quickly.
2. Maybe if I make all buffers global, I can verify some basics with a script. Gave up when I learned that "abstract interpretation" already exists, and it's way more advanced than anything I could whip up. (But kept the global buffers for now...)
3. The only example I found for a while was https://github.com/NASA-SW-VnV/ikos, but it needed an old version of Clang, and my laptop didn't have enough memory to build it.
4. Found a couple other examples that were clearly someone's research project.
5. Finally found Frama-C by searching through Fedora packages. And it's exactly what I needed.
There's definitely a learning curve, and it's not always obvious how to get it to do what you want. But I can at least install it, t
Read the rest
here's a nice GUI, and it's thoroughly documented.
I didn't hear of CBMC until later, but I see there a Fedora package for that too. Should probably take a crack at it!
I thought abstraction interpretation on the level that astree claims to implement is supposed to be extremely hard, which is why almost nobody else tries to do it. I only know of two that try:
http://kestreltechnology.com/technology.html
https://github.com/NASA-SW-VnV/ikos
In Astrée Static Analyzer for C and C++> https://www.absint.com/astree/index.htm
This looks interesting. It's based on abstract interpretation which is more or less the most powerful approach for imperative code available. (Because the way it works it's likely slow as hell though, I guess).
But it's closed source. One of this kind of products where you need to asks for the price… I think we all know what this means: It'll be laughably expensive.
I don't see any offer for OpenSource projects frankly.
> https://github.com/NASA-SW-VnV/ikos
Also abstract interpretation based. Looks less polished than the first one at first glance.
It's under some questionable license. According to OSI it's OpenSource. According to the FSF it's not. (The FSF argument sounds strong. They're right in my opinion. This NASA license does not look like OpenSource).
But an OpenSource project could use it
Read the rest
for free I assume.
> https://github.com/static-analysis-engineering/CodeHawk-C
Much more constrained in scope than the other ones. But looks a little bit "too academic" imho: Uses its own C parser and such.
At least it's OpenSource under MIT license.
Thanks for the links either way! Good to know about some tools in case one would need them at some point.
> I have planned to try using them on OpenZFS for a while, but I am still busy reviewing and fixing reports made by conventional static analyzers.
Stupid question about usual C development practices (as I don't have much contact with that):
Aren't analyzers today part of the build pipeline form the get go? Especially as C is known to be full of booby traps.
Imho it shouldn't be even possible to push anything that has issues discovered by tools.
This should be the lowest barrier as most code analyzers are at most able to spot quite obvious problems (the commercial one above is likely an exception to this "rule"). When even the usual "stupid analyzer" sees issues than the code is very likely in a very bad shape.
Adding such tools later on in the development is like activating warnings post factum: You'll get drowned in issues.
Especially in such critical domains as file-systems I would actually expect that the developers are using "the best tools money can buy" (or at least the best OpenSource tools available).
"Still fixing bugs found by some code analyzer" doesn't sound like someone should have much trust with their data in something like ZFS, to be honest… The statement sounds actually quite scary to me.
In theory, sound static analyzers could be another method by which this is achieved in existing projects. They claim to be able to catch all instances of this. Some examples of sound static analyzers include:
https://www.absint.com/astree/index.htm
https://github.com/NASA-SW-VnV/ikos
https://github.com/static-analysis-engineering/CodeHawk-C
I have planned to try using them on OpenZFS for a while, but I am still busy reviewing and fixing reports made by conventional static analyzers. I plan to look into these next.
That said, at least one of them claims to be able to prove the absence of issues in C that checked C’s documentation explicitly says it cannot prevent. The obvious one is use-after-free.
In Checked CThey have very unusual license which I have never seen before: https://github.com/NASA-SW-VnV/ikos/blob/master/LICENSE.txt
Is anyone familiar with it? Is it OSI certified? (it's not on the OSI's site).
In IKOS: Static analyzer for C/C++ based on the theory of Abstract InterpretationShowing the 15 most recent of 23 sources. Enable JavaScript to search and browse every indexed mention.