The issue is not with the allocator; the issue is with the ability to read or write beyond the bounds of an array. The fact that arrays are represented with pointers only worsens the problem. Even for low-level code, it never makes sense to step out of array bounds. Worse, though, is the fact that most C code is high-level, with no particular need or benefit from pointer acrobatics, and exposed to potentially malicious inputs.

A common refrain in these discussions is that C is good for some problem domains, and high level languages are good for others. The problem is that C is not being used only for one domain or some set of domains; it is being used everywhere. Web browsers and web servers are written in C. Email clients are written in C. Instant messaging programs. It is hard to see how my email program benefits from pointer acrobatics, unchecked array access, or a pile of undefined behavior -- so why was it written in C?

You could say this is my main issue. I can just assume that C is good in some domain, even if I never come across it; what I cannot understand is why high-level software is being written in a language that bogs programmers down with low-level concerns. Even implementing a small core in C, and the rest in a high-level language (e.g. Emacs) makes more sense than what we see today.

> The issue is not with the allocator; the issue is with the ability to read or write beyond the bounds of an array. ... Even for low-level code, it never makes sense to step out of array bounds.

You must understand that from the low level perspective, the array and its bounds do not exist. This is an abstraction. An allocator needs to chop up and slice a larger block of memory and give different segments to different callers. You cannot do this if something is enforcing bounds.

What you can do is build higher level abstractions that track bounds and do runtime checks at every access. In C there is nothing to stop you from doing that as a library. In C++, some STL implementations even have bounds checking as a compile time option. But the languages don't force you into paying that cost.

"An allocator needs to chop up and slice a larger block of memory and give different segments to different callers. You cannot do this if something is enforcing bounds."

Sure you can -- if the enforcement of array boundaries is based on types, and is not applied when dealing with a generic, low-level pointer type. Take a look at the implementation of SBCL (a Common Lisp compiler) to see this sort of thing in action.

Yes, building abstractions is the right thing to do, but libraries are the wrong way to do it. The problem with libraries is that the programmer needs to expend their mental energy on using the library, and needs to remember to not just use what the language provides them. If anything, the programmer should be forced to use a library to avoid bounds checking -- extra effort should be required to do dangerous things, rather than to be safe.

"the languages don't force you into paying that cost."

Neither do high-level languages, if you can guarantee that the cost does not need to be paid (and if you are using a half decent compiler). If your compiler can deduce that your array index cannot be out of bounds, it should generate code without a bounds check. That is why Lisp has type hints, and it is one of the arguments you hear in favor of static type checking.