HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
static-analysis-engineering
CodeHawk-C
Python2022–2022
static-analysis-engineering / CodeHawk-C

CodeHawk-C

CodeHawk C Analyzer: sound static analysis of memory safety (undefined behavior)

2Distinct people
2Mentions
0Explicit recommenders
33GitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

CodeHawk C Analyzer: sound static analysis of memory safety (undefined behavior)

GitHub

Where it is used

No documented product use has been verified yet.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these 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, 6:01:08 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by hour2 dated mentions

Observed mentions: 2022-12-21 22:22:18 UTC to 2022-12-21 23:40:39 UTC.

012022-12-21 22:00:00 UTC to 2022-12-21 23:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 commentsDec 21, 22:002022-12-21 23:00:00 UTC to 2022-12-22 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 commentsDec 21, 23:00

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
Dec 21, 22:002022-12-21 22:00:00 UTC2022-12-21 23:00:00 UTC101
Dec 21, 23:002022-12-21 23:00:00 UTC2022-12-22 00:00:00 UTC101

What Hacker News says

1 sources
> 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 Checked C

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.