> You can make your own explicit bounds checks, or you can use valgrind (which, just like any type system, can understand only simple situations). You can use C++ which actually does allow you to do bounds checking by default, if you're into such things.

Yeah, apparently Google, Apple, Microsoft think otherwise.

> Now tell me, why exactly is "new Foo[count]" safer than "ALLOCATE(Foo, count)"? Or just do this minimal boilerplate by hand, this is not a practical issue unless your code is very badly factored (good code requires only few allocations).

1 - Everyone needs to create their ALLOCATE macro, and not everyone does it right

2 - Actually it fails with certain kinds of type given as parameter

> I very much like that C keeps it simple and you always see what happens.

That is what people that never read ISO C and the myriad of UB cases think they do.

That is why I get such a kick of C Pub Quizzes, everyone is so full of themselves in regards to their C knowledge.

> This is why I took issue - you can't have both low-level bit twidding and "memory safe" programming. At most you can have a language that lets you choose between one or the other in a rather integrated system, but then you're still dealing with this abstraction gap, and having to traverse it constantly is not pleasant.

That is the whole point, dangerous code that can trigger memory corruption code should only be written when there is no way around to do it in a safer way.

And most of the time, it is an optimiser bug that is even the case to start with, unless one is writing drivers or kernel code.