Unless you have vm.overcommit_memory set to 1, then AIUI you can implement malloc s.t. a read/write to the returned memory won't generate a SIGSEGV, e.g. using

Unless you have vm.overcommit_memory set to 1, then AIUI you can implement malloc s.t. a read/write to the returned memory won't generate a SIGSEGV, e.g. using mmap sans MAP_NORESERVE. Even if vm.overcommit_memory=1, you can still (I assume) do it by simply having your malloc implementation populate each page. That said, as long as "too small to fail" (https://lwn.net/Articles/627419/ https://lwn.net/Articles/627419/) is around (which is presumably "forever"), the oom-killer won't be going away. Fork obviously compounds this massively due to copy-on-write. So ensuring your malloc'd memory is actually writable may just make you a more tempting target for the oom-killer. > Doesn't ISO C require that if malloc returns a nonzero pointer, it has to backed physically (need not be RAM, could be swap on disk or some other thing) I don't see anything like that, though admittedly I don't have a "real" copy of the standard. I'd also be at least a little surprised if it were true (though my being surprised by the C standard would...actually not be surprising). While the "spirit of the law" would probably make sense, the "letter of the law" would be difficult. Consider e.g. an otherwise side-effect free function with a statically computable result assuming a successful malloc (and corresponding free), could the compiler optimize away the malloc call?