title: Should I bother detecting OOM (out of memory) errors in my C code?
body: <p>I've devoted a large number of lines of C code to cleanup-labels/conditionals for failed memory allocation (indicated by the <code>alloc</code> family returning <code>NULL</code>). I was taught that this was a good practice so that, on memory failure, an appropriate error status could be flagged and <strong>the caller could potentially perform &quot;graceful memory cleanup&quot; and retry.</strong> I now have some doubts about this philosophy that I'm hoping to clear up.</p>
  <p>I guess it's <em>possible</em> that a caller could deallocate excessive buffer space or strip relational objects of their data, but <strong>I find the caller rarely has the capability</strong> (or is at the appropriate level of abstraction) to do so. Also, <strong>early-returning from the called function without side effects is often non-trivial.</strong></p>
  <p>I also just discovered the Linux OOM killer, which seems to make these efforts totally pointless on my primary development platform.</p>
  <blockquote>
  <p>By  default,  Linux  follows  an
  optimistic memory allocation strategy.
  This means that when malloc() returns
  non-NULL there  is  no  guarantee that
  the  memory  really  is available.
  This is a really bad bug.  In case it
  turns out that the system is out of
  memory, one  or  more  processes  will
  be  killed  by the infamous OOM
  killer.</p>
  </blockquote>
  <p>I figure there are probably other platforms out there that follow the same principle. <strong>Is there something pragmatic that makes checking for OOM conditions worthwhile?</strong></p>