Great!

This is something of a vicious circle: userspace doesn't check allocation success, so tends to allocate more than it needs (since allocating more memory than you will use doesn't cause any test failures, it will naturally tend to happen, just as other classes of error will inevitably creep in if the test suite and everyday usage does not cover them). So then the kernel has to allow overcommit - which means that userspace doesn't bother to check allocation... (There is also the vexed issue of fork() requiring overcommit, which has been discussed previously.)

I do agree that in practice, doing unchecked allocations may be the best tradeoff for a lot of code. Although I suggest that it needs better tools and runtime support to set limits: in my process, allocations made from *this* particular shared library should not exceed 100 megabytes total, while *that* function may only allocate at most 2 megs each time it is called... Since if libpng goes mad and develops a memory leak, I would much rather have the application die quickly (and with an informative message) than have it get slower and slower, thrashing the disk more and more until finally the OOM killer puts it out of its misery. Of course, breaking the program into several independent processes is one way to do this, but possibly with a bit more userspace accounting of memory usage the same goal could be achieved without needing separate processes.

However, safe allocation is not just for 'niche users', or if so, kernel programming is quite a large niche. And there may well be a case for writing small parts of your program in the checked-allocation style while leaving other parts to assume allocation never fails. So then if my app does go kaboom, at least I can be certain it wasn't my string class that did it.