Is there a need to check for NULL after allocating memory, when kernel uses overcommit memory

It is general practice to check for NULL (whether memory is successfully allocated) after a malloc(), some thing like

void *ptr = malloc(10);    
if (ptr != NULL) {  
  // do some thing usefull  
} else {  
 // no memory. safely return/throw ...  
}  

with memory overcommit enabled in kernel, is there a chance of getting NULL? Should I follow the practice of religiously checking NULL for each allocation? Will malloc return NULL inspite of aggresive overcommit mechanism (I guess value 1)?

As a matter of fact Android kernel uses memory overcommit (not sure about the value, would love to know it(overcommit value) and its significance). Some of the framework source(C/C++) code in Android (might be 3rd party) doesn't check for NULL nor catch bad_alloc after allocations. Am I missing something?

There are some threads in SO regarding overcommit memory, but none of them resolved my confusion.

EDIT: If aggressive overcommit is being employed NULL wont be returned(assumption 1). When there is no physical memory available and up on trying to access the allocated memory (write in to the memory allocated), OOM will kill some process and allocates memory for the application till it gets killed in turn(assumption 2). In either case i dont see any need for cheking NULL 开发者_开发百科(memory getting allocated or process getting killed). am i right in my assumptions?

Portability is not a concern for this question.

Yes, you should still check for failures returned by malloc. In an environment that overcommits memory you will not be able to detect and recover from failures due to the environment running out of physical storage required when you write to parts of the address space that have been allocated to your program by a previous call to malloc.

However, this is not the only problem that would cause a malloc to fail in a traditional environment. A request for a particularly large block of memory when the address space of your program has become fragmented may fail even if there is potentially enough total physical memory to satisfy the request. Because there is no contiguous range of free address space malloc must fail. This type of failure must be signaled by malloc returning NULL, whether or not the environment is overcommitting memory.

You must check return value for NULL every time. Any library function can fail. Even fclose() do (on disconnected NFS share, and error from fclose of NFS file means, that data was not saved).

The most of software is badly written and doesn't contain all checks.

malloc can't return something other than NULL or pointer. All-or-nothing. You can't get 1 byte from malloc if you ask for 10.

It would be advisable to check for NULL religiously across all functions calls that may return NULL, regardless of whether the kernel has over-committable memory or not.

This following code segment below shows how to check if the call to malloc worked or not...

void *ptr = malloc(10);
if (ptr != NULL){
   /* Do something here with ptr */
}else{
   /* Do something here if it fails */
}

File operations, memory operations to name but a few will return a NULL upon failure.

Hope this helps, Best regards, Tom.

well...on Linux since memory is not page backed (initially) and only creates page backing after first read/write, the OS will always succeed to give you memory (unless you exhausted the address space, something not possible in 64 bit systems). So if it runs out of memory and cannot give you the promised memory, OOM killer will just kill your application or some other application to give you the page backing you need. So whether you do the NULL check or not, the out come is the same, a crash.......

No, there is no need to check the result of malloc.

Long before malloc would fail, the operating system had already encountered a lot of problems.

"OOM-Killer and overcommit" would be a better choice.

What? Your operating system does not support "OOM-Killer and overcommit"?

This is why you should switch to Linux （or Android）!