The Parable of the Null Pointer for Lazy C Programmers

I agree that a memory allocation error using malloc is a rare situation, and after such an error, the full functioning of the program is most likely impossible. But I am surprised by how persistently programmers, citing these arguments, suggest doing nothing at all in such a situation. I'm not advocating for everyone to make complex recovery mechanisms after running out of memory or to use pre-allocated backup buffers. Many programs don't need such complex mechanisms. However, I don’t understand why such situations cannot be handled at least minimally correctly. Since there aren’t enough other explanations yet, I’ll try to tell a short parable this time.

This article is an extended commentary for discussions on some platforms. Therefore, if you are not in the context, then I first refer you to these two publications:

Parable

Once upon a time there was a software company. They had a big client who paid a lot of money and everything was fine. But then this client began to complain that some users' applications began to crash.

It seems clear why it crashes – null pointer dereference. It’s clear, but it’s not clear, since the developers cannot reproduce the problem themselves. Moreover, the client works with private data. It will not send you a stack trace or a dump, and will not allow you to conduct a remote debugging session.

The client is increasingly annoyed by this matter. Something needs to be done. The company sends developers with source codes and debug versions to the customer’s office. So that they look for the bug under supervision and in a closed circuit.

It’s an expensive pleasure to distract the team, especially since they had to go to another country.

They found a bug. On some 32-bit Windows machines there was little memory, or the page file was small. Sometimes there was not enough memory. Memory allocation function malloc returned NULL. The null pointer was dereferenced and the program crashed.

So why was it so difficult to understand all of this at once? But because the programming team was lazy and did not check that the function malloc returns. They thought that since there was no memory, nothing could be done anyway. Let the program crash. It crashed with a message about a null pointer.

The program could at least print “Out of memory”. This would reduce research time. The team would not have to be sent anywhere, and it would be possible to quickly find out what kind of characteristics and settings the machines on which this happens are. Moreover, the client would be more satisfied with the quality of the software.

Here is a story that either happened or didn’t. I am writing this because there are programmers who continue to challenge simple things. They are looking for reasons why there is no need to write a check, instead of just writing code that adequately responds to various situations.

Morality

Don't be lazy. Process the pointer that the function returned malloc (realloc, calloc, strdup etc.). Yes, verification may not be useful in practice. Perhaps there will always be enough memory. But what, you feel sorry, or what? Write reliable code. Don't be like those programmers from the parable.

If you want to share this article with an English-speaking audience, please use the translation link: Andrey Karpov. Parable of null pointer for indolent C programmers.