CompCert VS ikos

A big problem is that proving that transformations preserve semantics is very hard. Formal methods has huge potential and I believe it will be a big part of the future, but it hasn't become mainstream yet. Probably a big reason why is that right now it's simply not practical: the things you can prove are much more limited than the things you can do, and it's a lot less work to just create a large testsuite.

Example: CompCert (https://compcert.org/), a formally-verified compiler AKA formally-verified sequence of semantics-preserving transformations from C code to Assembly. It's a great accomplishment, but few people are actually compiling their code with CompCert. Because GCC and LLVM are much faster[1], and have been used so widely that >99.9% of code is going to be compiled correctly, especially code which isn't doing anything extremely weird.

But as articles like this show, no matter how large a testsuite there may always be bugs, tests will never provide the kind of guarantees formal verification does.

[1] From CompCert, "Performance of the generated code is decent but not outstanding: on PowerPC, about 90% of the performance of GCC version 4 at optimization level 1"

Also a C compiler (https://compcert.org/). I did exaggerate bit in saying that anything non-trivial is "nearly impossible".

However, both CompCert and sel4 took a few years to develop, whereas it would only take months if not weeks to make versions of both which aren't formally verified but heavily tested.

From my experience, while many MCUs have settled for the big compilers (GCC and Clang), DSPs and some FPGAs (not Intel and Xilinx, those have lately settled for Clang and a combination of Clang and GCC respectively) use some pretty bespoke compilers (just running ./ --version is enough to verify this, if the compiler even offers that option). That's not necessarily bad, since many of them offer some really useful features, but error messages can be really cryptic in some cases. Also some industries require use of verified compilers, like CompCert[1], and in such cases GCC and Clang just don't cut it.

[1]: https://compcert.org/

CompCert sends its regards

But that's fine, because we can do even better with things like the CompCert C compiler, which is formally proven to produce correct asm output for ISO C 2011 source. It's designed for high-reliability, safety-critical applications; it's used for things like Airbus A380 avionics software, or control software for emergency generators at nuclear power plants. Software that's probably not overly sophisticated and doesn't need to be highly optimized, but does need to work ~100% correctly, ~100% of the time.

For context, CompCert is a formally verified compiler. My former advisor helped with a fuzzer called CSmith which found plenty of bugs in GCC and LLVM but not in CompCert.

Does anybody know how does this compare to https://compcert.org/ ?

This is a common property for proof-oriented languages. Coq shares this property for instance, and you can write an optimizing C compiler in Coq: https://github.com/AbsInt/CompCert .

I 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 generate 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've been playing around with running IKOS (https://github.com/NASA-SW-VnV/ikos), it sounds very cool but doesn't seem to be super well maintained. I've managed to compile my project to llvm bit-code and run the IKSO on it, but the actual analysis seems to be buggy. There are open issues for the problems I encountered, but the make the analysis pretty useless (it thinks most functions are unreachable).

> 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 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.

They 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).

Yeah there are tools that require adding contracts as comments. But again, there are also friction-less tools that don't require any changes (for example a NASA one).