Always check malloc'ed memory?

Question

I often catch myself doing the following (in non-critical components):

some_small_struct *ptr=(some_small_struct *) malloc(sizeof(some_small_struct));
ptr->some_member= ...;

In words, I allocate dynamically memory for a small structure and I use it directly without checking the malloc'ed pointer. I understand there is always a chance that the program won't get the memory it asks for (duh!) but consider the following:

If the program can't even get some memory for a small structure off the heap, maybe there are much bigger problems looming and it doesn't matter after all.

Furthermore, what if handling the null pointer exacerbates the precarious situation even more?? (e.g. trying to log the condition calls even more non-existing resources etc.)

Is my reasoning sane (enough) ?

Updated:

1. A "safe_malloc" function can be useful when debugging and might be useful otherwise
2. +X access can hide the root cause of a NULL pointer
3. On Linux, "optimistic memory allocation" can shadow loomin OOM (Out-Of-Memory) conditions

Answer 1

I always feel it is important and best to handle the return of malloc or any other system call for that matter. Though in modern systems (apart from embedded ones) it's a rare scenario unless and until your code uses too much memory, it's always safer.

Continuing the code after a system call failure can lead to corruption, crash and what not apart from making your program look bad.

Also, in linux, memory allocated to a process is limited. Try creating 1000 threads in a process and allocate some memory in each one of them, then you can easily simulate the low memory condition. : )

Always better to check for sys call return values!

Answer 2

In the case of C, it depends on the platform. If you are on an embedded platform with very little memory, you should alweays check, thouggh what you do if it does fail is more difficult to say. On a modern 32-bit OS with virtual memory, the system will probably become unresponsive and crash before it admits to running out of memory. In this case, the call to malloc never returns, so the utility of checking its value becomes moot.

In the case of C++, you should be using new instead of malloc, in which case an exception will be raised on exhaustion, so there is no point in checking the return value.

Answer 3

I would say No. Using a NULL pointer is going to crash the program (probably).
But detecting it and doing something intelligent will be OK and you may be able to recover from the low memory situation.

If you are doing a big operation set some global error flag and start unwinding the stack and releasing resources. Hopefully one or more of these resources will be your memory hog and your application will get back to normal.

This of course is a C problem and handeled automatically in C++ with the help of exceptions and RAII.
As new will not return NULL there is no point in checking.

Answer 4

It is possible to allocate a largish chunk of memory at startup that you can free when you hit an out of memory condition and use that to shut down gracefully.

Answer 5

at the very least I would put an assert(ptr != NULL) in there so you get a meaningful error.

Answer 6

Furthermore, what if handling the null pointer exacerbates the precarious situation even more??

I do not see why it can exacerbate the situation.
Anyway, when writing code for windows ptr->some_member will throw access violation so you will immediately see the problem, therefore I see no reason to check the return value, unless your program has some opportunity to free the memory. For platforms that do not handle null-pointers in a good way(throwing exception) it is dangerous to ignore such points.