Indeed. But the fact that the kernel does it at all is mysterious, and that on most systems the misfeature is enabled by default...

The reason it is there is that the C memory allocation model tends to ask for rather more memory than the program actually needs. This leads to inefficiency if all that unused memory is backed by physical memory. So this overcommit trick was created to allow other processes to 'steal pages' from processes that have allocated memory but have decided not to use them for now. In practice this works reasonably well, but there are some nasty edge cases when one or more of those programs wake up and then decide to actually use the memory they think they already have.

For systems where deterministic behavior is more important than flexibility (for me: all of them, for others: their choice) you're better off disabling overcommit.

I don't think there is no such thing as a "C memory allocation model". There are various ways of requesting memory from the OS. But not requesting anything in advance is going to be very slow in any setting that requires a context switch or virtual memory.

A typical memory manager will scale up the size of the requests to the OS whenever it runs out of space.