Our website uses cookies to enhance your browsing experience.
Your message has been sent. We will email you at
If you haven't received our response, please do the following:
check your Spam/Junk folder and click the
"Not Spam" button for our message.
This way, you won't miss messages from our team in the future.
I agree that a memory allocation error with malloc is quite rare case, and after such an error it's most likely that the program can't fully function. But I'm bewildered how programmers persistently talk about it and then offer to do nothing. I don't call upon everyone to write intricate mechanisms to recover from low memory or use the preallocated backup buffers. Many programs don't need such difficult mechanisms. However, I don't understand why developers can't at least correctly handle these cases. Since my previous explanations don't work out, I'll try to tell you a short parable.
This article is an extended comment for discussions in some social medias. So, if you don't understand what I'm talking about, take your time to read two previous publications:
The parable
Once upon a time there was a software company. It had a big-big client who was paying lots and lots of money, and everything was going well. But then the big-big client complained that some users had experienced apps crashing.
It seemed clear why it had crashed — a null pointer dereference. Clear, but not really... as the developers couldn't reproduce the error. Moreover, the client worked with the private data. The client won't send you the stack trace or dump, the client won't let the devs do a remote debugging.
Meanwhile, the client was getting more and more irritated. The developers had to do something. The software company sent the developers with source code and debug versions to the client's office. They should find a bug under the client's watchful eye in a closed loop.
Pricey, wasn't it? The software company should also distract the dev's team like that, especially since they had to fly to another country.
They found the bug. Some 32-bit Windows machines had low memory or a small swap file. Sometimes there was not enough memory. The malloc function returned NULL. The null pointer was dereferenced and the program crashed.
Why was it difficult to figure everything out at once? It was because the dev's team didn't want to waste their time and check what the malloc function returned. They thought that since there was not enough memory, there was nothing they could do anyway. So, they let the program crash. It crashed displaying the message about a null pointer.
The program could at least display "Out of memory". It would shorten the research time. The dev's team wouldn't have to be sent to the client's office, and they could quickly find out what the specs and settings were on the machines where it happened. And the client would be more satisfied with the software quality.
That's the end of the story, whether it was or not — no one knows. I covered this because developers keep arguing about simple things. They're still looking for explanations why you shouldn't write a check instead of writing code that will properly handle different cases.
The moral
Don't be indolent. Handle the pointer that the malloc function returned (realloc, calloc, strdup, etc.). Yes, the check may not be useful in real circumstances. The memory may always be enough. So, is that a big deal? Write reliable code. Don't be like programmers from the parable.
0
0
0
56
0
0