You beat me to it. Unlike the other commenters, I see that you&#x27;re describing it as a robust, predictable start to what Bernstein describes. Undefined behavior and other problems can be caught by extensions to the compiler or via static analysis tools like an Astree Analyzer knockoff. The fact that they&#x27;ll be written in Ocaml (or SML) will make them more reliable. A good choice and what I&#x27;ve promoted here so far.<p>Additionally, the clean passes are easier to bootstrap for those that fear subversion of their compiler. Can use whatever you want on whatever machine to implement it. So long as code matches spec, the output should be the same. That implementation compiles the other compilers, verifiers, whatever.<p>You might also enjoy that people have already extended CompCert work and others for developments that push in the Boring, Safe&#x2F;Secure, C compiler direction. Here&#x27;s some:<p>CakeML - Compile CompCert, etc with this
<a href="https:&#x2F;&#x2F;cakeml.org&#x2F;" rel="nofollow">https:&#x2F;&#x2F;cakeml.org&#x2F;</a><p>Verasco - verified, CompCert-based, static analyzer for C
<a href="http:&#x2F;&#x2F;compcert.inria.fr&#x2F;verasco&#x2F;" rel="nofollow">http:&#x2F;&#x2F;compcert.inria.fr&#x2F;verasco&#x2F;</a><p>Verification of LLVM transformations later work (eg Softbound or Code-pointer Integrity clone)
<a href="http:&#x2F;&#x2F;repository.upenn.edu&#x2F;dissertations&#x2F;AAI3592852&#x2F;" rel="nofollow">http:&#x2F;&#x2F;repository.upenn.edu&#x2F;dissertations&#x2F;AAI3592852&#x2F;</a><p>Extension of CompCert for verified, WCET analysis
<a href="https:&#x2F;&#x2F;hal.inria.fr&#x2F;hal-01087194" rel="nofollow">https:&#x2F;&#x2F;hal.inria.fr&#x2F;hal-01087194</a><p>So, lots of good stuff being done by a subset that focus on right design methods with the right tools. And they&#x27;re getting incredible results. Surprise! :)