title: Is there a need to check for NULL after allocating memory, when kernel uses overcommit memory
body: <p>It is general practice to check for NULL (whether memory is successfully allocated) after a malloc(), some thing like</p>
  
  <pre><code>void *ptr = malloc(10);    
  if (ptr != NULL) {  
    // do some thing usefull  
  } else {  
   // no memory. safely return/throw ...  
  }  
  </code></pre>
  
  <p>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)?</p>
  
  <p>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?</p>
  
  <p>There are some threads in SO regarding overcommit memory, but none of them resolved my confusion.</p>
  
  <p><b>EDIT:</b> 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?<br>
  <b>Portability is not a concern for this question.</b></p>