> malloc() return isn't checked
small digression, but I thought that at least on Linux, malloc() never returns an error because the actual allocation happens lazily, when the memory is first used?
small digression, but I thought that at least on Linux, malloc() never returns an error because the actual allocation happens lazily, when the memory is first used?
The default overcommit-within-reason algorithm is designed to deny allocations that are obviously unrealistic I think.
Using semi conservative ulimit settings is pretty common in interactive use to catch runaway / swapped to death situations.
Also, on Linux, only 48 of 64 bits are available for VM addressing. That leaves you with about 250TB of address space. Seems like a lot until you start using VM for disk mmaps. I have actually seen this limit hit.
That is on amd64, not linux. And arm does the same thing. (It's also 256tb, not 250tb.)
Newer intel cpus use 5-level paging[1], which gives you 128pb VM.
On 32 bits malloc is going to fail once your virtual memory space is full (~3 GB).
Error checking is somewhat redundant for most applications, since you're going to abort anyway, and if there are no pages available on access - well you're getting SIGSEGV anyway, just like you would accessing a null pointer (except on embedded devices). But beware of the exceptions. In C especially it's common to use null pointers as a flag... one of the reasons why new/delete in C++ is preferable; it throws and thus aborts when it fails, which you don't care to handle, so that's about perfect for a C++ exception.
And that's part of the "and do it well". A thousand years from now, if the C99&POSIX spec survives, will support correctly written code.
Dereferencing a null pointer can also be a security issue (mostly for kernels, though) so one should assume a malicious general environment.