The correct solution is for the next C standard to no longer leave anything behaviour undefined.
That’s occasionally been floated during the revisions, but most people aren’t willing to pay the performance hit it would imply, so most of the undefined behavior has stayed there. Chris Lattner has a decent summary of some of the issues here. For example, C currently leaves it undefined what happens when you dereference an invalid pointer. This allows compilers to just “blindly” compile unchecked pointer dereferences. What happens when one is invalid? Well, whatever the underlying platform does with it: maybe it traps or segfaults, maybe it returns random bits of someone else’s memory, maybe it silently returns 0, who knows— it’s left up to the hardware and OS you’re running on. If you defined that behavior, for example by requiring invalid pointer dereferences to trap, every pointer dereference would have to be runtime range-checked, except those that you can statically prove are valid.
Ooh, perhaps a new compiler for OpenBSD base one day. (R.I.P. pcc)
I agree that this would be a great project for a crowdfunding campaign.
Non-mobile direct link.
I would really like to see a compiler like this. Tools like valgrind, while providing a lot, can’t rewrite your code for you. They also tend to be slow on large projects. Hopefully, if this ever gets built, much of that work can be shifted into the compilation phase providing a slightly better ux for checks like this.
I wonder how realistic this is; Dr Bernstein certainly has forgotten more about the security implications of the lousy C standard than I’ll ever know about anything, so take my following “but” with the appropriate level of skepticism …
But. Isn’t the problem mostly one with the culture of C programming in specific, and the economics of software development, in general? I guess Dr Bernstein isn’t trying to solve the general problem of C as much as, by adhering to the C ABI, giving careful and security conscious developers a bridge out of the undefined mess, but that still seems a little like whistling past the graveyard of safer C replacement languages.
I think the real problems are the path dependencies and human inertia that keeps us using C full stop.
I think this is quite realistic, and people are misunderstanding what this is trying to do. To quote, “my goal here isn’t to design a new language; it’s to provide predictable behavior for the existing C code base”.
I am more skeptical about the claim that “a boring C compiler will very quickly gain users” and it is “what most C programmers want”, but I think the claim is worth testing and the only way to test is to write a boring C compiler.
[P]eople are misunderstanding what this is trying to do
Yes, I certainly did. Upon a closer re-reading, the idea (as I understand it) is to provide something of a safe place for important codes, free of the uncertainty of less boring compilers.
The real problem, currently, is that there are a lot of folks whose academic and professional careers are founded upon making breaking or subversive changes to the existing compiler technology and then handwaving about “undefined behavior” whenever they’re called out on it. There seems to be very little sympathy (or taste) regarding existing userland code, and that’s how we’ve gotten into this mess.
Fixing the spec is certainly a solution to part of the problem, but one can imagine that that sort of work is far less glamorous than including more metaprogramming features and library functions.