DieHard: An error-resistant memory allocator for Windows, Linux, and Mac OS X

To accommodate SimCity (and I strongly suspect other programs), Windows would detect it and run a special version of the deallocator that allowed its form of use after freeing (see e.g. http://www.joelonsoftware.com/articles/APIWar.html).

I've been using C since ~ 1980 (sic), loathe C++, and, yeah, I'm going to investigate Rust in due course.

I think there is a misconception around GC, you could still be retaining memory you didn't intend to. It won't lead to a dangling pointer, but there is still a need for some kind of assertion of the effect: "I know this object should be collected at this point in time", and some complex tools to analyse the retention path. Because even if the object is still valid on a memory point of view, it could still be in a inconsistent state if you thought it was not retained, but it is, and now it goes into a pipeline of code that can't handle its state etc. Imagine a closed file handle that you forgot to remove from a collection or something like that.

The memory errors in C++ are not exactly memory error, they are, like other errors, a misconception on the state of the object graph. And it's hard to find and fix.

What you are referring to is not DieHard but rather Exterminator. DieHard probabilistically tolerates memory errors, while Exterminator repairs them.

Both rely on a carefully designed semantics under which one can provide a reasonable interpretation for erroneous computations. They employ sophisticated randomized algorithms and/or statistical inference procedures and contain proofs of their effectiveness. That's not exactly a hack.

The fact is that managed languages that provide memory safety guarantees -- through strong type systems, mandatory bounds checks and automatic memory management -- are of course preferable to C/C++/Objective-C from a software engineering perspective.

But the fact also remains that most of the code we use today is written in unsafe languages, including the runtime systems that undergird managed languages. Since these programs almost certainly contain errors, it makes sense to accept that fact and work to provide solutions.

I'd encourage you to read this article, which appeared in Communications of the ACM - "Software Needs Seatbelts and Airbags", which contains an in-depth discussion of these issues.

http://cacm.acm.org/magazines/2012/9/154577-software-needs-s...

That content, which initially appeared in ACM Queue, is freely available here on my blog:

http://emeryblogger.com/2012/05/31/software-needs-seatbelts-...

I think there are compiler flags available that will do this (at least the bounds checking).

When talking about C it's important to understand why the standard is the way it is. C was designed to be a portable language. Not in the sense that code is easily portable, but that the language itself is easily portable by writing a new compiler for it on whatever OS you're using. As such, the C standard is written to make C an easy language to write a compiler for, which is why it has so much undefined behavior.

> Why can't the C standards committee

Wrong people. It would be the compiler writers who would do that, since they know the target machine.

Actually, the codebase continues to be actively updated.