https://groups.google.com/forum/m/#!msg/boring-crypto/48qa1k...
But I have to say, if one is going to do this, then C isn't a good target. Especially for crypto, C lacks extremely useful semantics such as rotate-left, rotate-right, add-with-carry, subtract-with-borrow, etc. Things that would greatly accelerate libraries that work with 512-bit multiplies like DJB's Curve25519. And then there's useful math operators like power-of that could be added.
You could also put requirements in there like "warn/error on variable-length divide" to catch surprise gotchas like x86 CPUs taking an indeterminate length of time to divide. In fact, constant-time execution could be a compile-time check.
The key would be to keep it "as much C" as possible. Rust and co are going to face barriers by being so incredibly different from C.
In any case, LSSL can be a heck of a lot safer than OSSL, and, in fact, already is.
(And is what rustls uses)
It was a great experience in the mid-90's, but a modern language in 2016 requires much more that what it offered, hence why I eventually got disappointed with Go's feature set.
I would rather see Ada, SPARK, Swift, Rust, ATS, Idris, F*, Formal Methods or whatever else that ensures that our code runs on top of solid foundations.
In any case, my point still stands: People aren't going to rewrite all that C code. The best we can hope for is for some UB to actually be standardized, so that the sociopaths who write the compilers are reigned in a bit.
Since I know C (1992), I have seen quite a few times people write code to go fast as they can and apply compiler optimization tricks for use cases where it hardly matters.
Also many of the issues regarding UB go back to the early ANSI C days, when it was the wild west of C dialects outside UNIX and no vendor wanted to give up on their own extensions.
As for C and C++ compiler writers view on UB:
C's culture of hyper-optimization is ridiculous. Unfortunately, while Rust may well eat C++'s lunch, there's very little that is competitve with C at the same level of abstraction, so for some work (kernel development, perhaps, embedded systems, definately) it will remain significant for some time, if not outright dominant.