Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > When to check the return value of malloc

Reply
Thread Tools

When to check the return value of malloc

 
 
CBFalconer
Guest
Posts: n/a
 
      01-19-2008
Randy Howard wrote:
> Eric Sosman wrote
>> Marty James wrote:
>>
>>> I was reflecting recently on malloc.
>>>
>>> Obviously, for tiny allocations like 20 bytes to strcpy a
>>> filename or something, there's no point putting in a check on
>>> the return value of malloc.

>>
>> "Obviously," you can allocate an infinite amount of
>> memory as long as you get it in 20-byte chunks? Did you
>> used to work for Enron or something?

>
> This thread was useful, now I know I never have to buy extra
> memory again.


PROVIDED you malloc it in 20 byte chunks. Since the standard
specifies that freed memory be made available again, you must be
perfectly safe in allocating 4k by:

for (i = 0; i < 20; i++) a[i] = malloc(20);
for (i = 0; i < 20; i++) free(a[i]);
ptr = malloc(4000);

with suitable declarations for a, i, ptr, and all the needed
#includes. Learning is wunnerful.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.



--
Posted via a free Usenet account from http://www.teranews.com

 
Reply With Quote
 
 
 
 
user923005
Guest
Posts: n/a
 
      01-19-2008
On Jan 18, 1:21*pm, Marty James <(E-Mail Removed)> wrote:
> Howdy,
>
> I was reflecting recently on malloc.
>
> Obviously, for tiny allocations like 20 bytes to strcpy a filename or
> something, there's no point putting in a check on the return value of
> malloc.
>
> OTOH, if you're allocating a gigabyte for a large array, this might
> fail, so you should definitely check for a NULL return.
>
> So somewhere in between these extremes, there must be a point where you
> stop ignoring malloc's return value, and start checking it.
>
> Where do people draw this line? I guess it depends on the likely system
> the program will be deployed on, but are there any good rule-of-thumbs?


The good rule of thumb is always check.

True story about an OS/2 application for fielding telephone messages:
While I was working as a subcontracor at a large corporation nearby
some 18 years ago or so, there was an OS/2 application that did
zillions of 16 byte allocations and frees. No big "gimmie a
megabyte!" demands at all. The machine had 4 MB {IIRC}, which at the
time was *cough* a lot of memory. Now, according to the statistics I
examined, the packet creation and packet deletion was at a sort of
homeostatis that should have never seen a failure. However, the
memory allocater for OS/2 had a bad habit of fragmenting memory in
some very bizarre ways if there were lots and lots of very rapid
malloc()/free() pairs. The end result is that those 16 byte
allocation requests would eventually start to fail. Since there was
no check for malloc() success in the code [I DIDN'T WRITE IT!] it
crashed heinously. My first stab at fixing it (after putting in
diagnosics to at lest describe the problem before exiting) was to call
a non-standard "CompactMemory()" routine at regular intervals. At
first, it seemed to fix the problem but it lead to to other problems.
The system had to be near real time, and the compact memory call would
freeze it up momemtarily and also, it would eventually start to fail
again anyway (even though it would run much longer before failure).
My final solution was to allocate most of available RAM into a single
block and then I wrote my own sub-allocator. It was actually very
simple because all the packets were the same size, and so I just
tagged them as free or in use with an array of bits.

So, even if you do not allocate any big memory hunks and even if you
know that all of the allocations should succeed, you should still
check them. Because things don't always behave the way that you know
that they should.

IMO-YMMV.
 
Reply With Quote
 
 
 
 
user923005
Guest
Posts: n/a
 
      01-19-2008
On Jan 18, 7:39*pm, CBFalconer <(E-Mail Removed)> wrote:
> Randy Howard wrote:
> > Eric Sosman wrote
> >> Marty James wrote:

>
> >>> I was reflecting recently on malloc.

>
> >>> Obviously, for tiny allocations like 20 bytes to strcpy a
> >>> filename or something, there's no point putting in a check on
> >>> the return value of malloc.

>
> >> * * *"Obviously," you can allocate an infinite amount of
> >> memory as long as you get it in 20-byte chunks? *Did you
> >> used to work for Enron or something?

>
> > This thread was useful, now I know I never have to buy extra
> > memory again.

>
> PROVIDED you malloc it in 20 byte chunks. *Since the standard
> specifies that freed memory be made available again, you must be
> perfectly safe in allocating 4k by:
>
> * *for (i = 0; i < 20; i++) a[i] = malloc(20);
> * *for (i = 0; i < 20; i++) free(a[i]);
> * *ptr = malloc(4000);
>
> with suitable declarations for a, i, ptr, and all the needed
> #includes. *Learning is wunnerful.
>


You might be perfectly safe to allocate (say) 64K according to the ISO
C Standard. But the other program that is running and has consumed
all but 19 free bytes before your program executes the first malloc()
doesn't know that.
 
Reply With Quote
 
user923005
Guest
Posts: n/a
 
      01-19-2008
On Jan 18, 9:41*pm, user923005 <(E-Mail Removed)> wrote:
> On Jan 18, 7:39*pm, CBFalconer <(E-Mail Removed)> wrote:
>
>
>
>
>
> > Randy Howard wrote:
> > > Eric Sosman wrote
> > >> Marty James wrote:

>
> > >>> I was reflecting recently on malloc.

>
> > >>> Obviously, for tiny allocations like 20 bytes to strcpy a
> > >>> filename or something, there's no point putting in a check on
> > >>> the return value of malloc.

>
> > >> * * *"Obviously," you can allocate an infinite amount of
> > >> memory as long as you get it in 20-byte chunks? *Did you
> > >> used to work for Enron or something?

>
> > > This thread was useful, now I know I never have to buy extra
> > > memory again.

>
> > PROVIDED you malloc it in 20 byte chunks. *Since the standard
> > specifies that freed memory be made available again, you must be
> > perfectly safe in allocating 4k by:

>
> > * *for (i = 0; i < 20; i++) a[i] = malloc(20);
> > * *for (i = 0; i < 20; i++) free(a[i]);
> > * *ptr = malloc(4000);

>
> > with suitable declarations for a, i, ptr, and all the needed
> > #includes. *Learning is wunnerful.

>
> You might be perfectly safe to allocate (say) 64K according to the ISO
> C Standard. *But the other program that is running and has consumed
> all but 19 free bytes before your program executes the first malloc()
> doesn't know that.- Hide quoted text -
>
> - Show quoted text -


Sorry, sarcasm detector switch was broken off, and laying on the
floor.
 
Reply With Quote
 
Ulrich Eckhardt
Guest
Posts: n/a
 
      01-19-2008
Marty James wrote:
> I was reflecting recently on malloc.
>
> Obviously, for tiny allocations like 20 bytes to strcpy a filename or
> something, there's no point putting in a check on the return value of
> malloc.
>
> OTOH, if you're allocating a gigabyte for a large array, this might
> fail, so you should definitely check for a NULL return.
>
> So somewhere in between these extremes, there must be a point where you
> stop ignoring malloc's return value, and start checking it.
>
> Where do people draw this line? I guess it depends on the likely system
> the program will be deployed on, but are there any good rule-of-thumbs?


As you have seen, the general attitude is to always check, and I actually am
one of that crowd. However, I do it slightly different:

void* xmalloc(size_t s) {
void* res = malloc(s);
if(!res) {
fprintf( stderr, "malloc() failed\n");
exit(EXIT_FAILURE);
}
return res;
}

Just like that, it stands in every program that is simply not prepared to
handle OOM conditions. In the code then, when I e.g. allocate temporary
storage to compose a filename, I just call xmalloc() and never check its
result, because I know that it either succeeded or exit()ed. Now, for
larger allocations I might still use malloc() and check the result, but I
mostly don't bother.

Note that this strategy is not always applicable, typically only to
short-running programs (like e.g. a compiler) but not to e.g. server
programs where the failure must be limited to the particular request only.
(But I wouldn't write those in C either...).

Further, the same strategy can of course be applied to other functions like
realloc(), fopen() etc. Whenever you can't sensibly recover from a resource
shortage, just exit with a meaningful error message.

Uli

 
Reply With Quote
 
Randy Howard
Guest
Posts: n/a
 
      01-19-2008
On Fri, 18 Jan 2008 23:41:49 -0600, user923005 wrote
(in article
<(E-Mail Removed)>):

> On Jan 18, 7:39*pm, CBFalconer <(E-Mail Removed)> wrote:
>> Randy Howard wrote:
>>> Eric Sosman wrote
>>>> Marty James wrote:

>>
>>>>> I was reflecting recently on malloc.

>>
>>>>> Obviously, for tiny allocations like 20 bytes to strcpy a
>>>>> filename or something, there's no point putting in a check on
>>>>> the return value of malloc.

>>
>>>> * * *"Obviously," you can allocate an infinite amount of
>>>> memory as long as you get it in 20-byte chunks? *Did you
>>>> used to work for Enron or something?

>>
>>> This thread was useful, now I know I never have to buy extra
>>> memory again.

>>
>> PROVIDED you malloc it in 20 byte chunks. *Since the standard
>> specifies that freed memory be made available again, you must be
>> perfectly safe in allocating 4k by:
>>
>> * *for (i = 0; i < 20; i++) a[i] = malloc(20);
>> * *for (i = 0; i < 20; i++) free(a[i]);
>> * *ptr = malloc(4000);
>>
>> with suitable declarations for a, i, ptr, and all the needed
>> #includes. *Learning is wunnerful.
>>

>
> You might be perfectly safe to allocate (say) 64K according to the ISO
> C Standard. But the other program that is running and has consumed
> all but 19 free bytes before your program executes the first malloc()
> doesn't know that.


Both of you need to get a sense of humor.

--
Randy Howard (2reply remove FOOBAR)
"The power of accurate observation is called cynicism by those
who have not got it." - George Bernard Shaw





 
Reply With Quote
 
Bart C
Guest
Posts: n/a
 
      01-19-2008

"Marty James" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> Howdy,
>
> I was reflecting recently on malloc.
>
> Obviously, for tiny allocations like 20 bytes to strcpy a filename or
> something, there's no point putting in a check on the return value of
> malloc.
>
> OTOH, if you're allocating a gigabyte for a large array, this might
> fail, so you should definitely check for a NULL return.
>
> So somewhere in between these extremes, there must be a point where you
> stop ignoring malloc's return value, and start checking it.
>
> Where do people draw this line? I guess it depends on the likely system
> the program will be deployed on, but are there any good rule-of-thumbs?


If checking is that much trouble then create a wrapper function around
malloc() that will always return a valid result. (The wrapper will check for
NULL results of malloc() and abort or do other exception code.) Then call
that instead of malloc(). This way you dispense with checking every time.

Use this when allocation failure is (a) unimportant or (b) very important
(that the program cannot proceed). (Seems paradoxical I know.)

To take some other action when allocation fails then call malloc() in the
regular way.

Bart



 
Reply With Quote
 
Malcolm McLean
Guest
Posts: n/a
 
      01-19-2008

"Marty James" <(E-Mail Removed)> wrote in message
> Obviously, for tiny allocations like 20 bytes to strcpy a filename or
> something, there's no point putting in a check on the return value of
> malloc.
>
> OTOH, if you're allocating a gigabyte for a large array, this might
> fail, so you should definitely check for a NULL return.
>
> So somewhere in between these extremes, there must be a point where you
> stop ignoring malloc's return value, and start checking it.
>
> Where do people draw this line? I guess it depends on the likely system
> the program will be deployed on, but are there any good rule-of-thumbs?
>

Yes.
Imagine you've got 2GB installed and are allocating 20 bytes. The system is
stressed and programs crash or terminate for lack of memory once a day. Any
more than that, and no-one would tolerate it.
So the chance the crash being caused by your allocation is 1/ 100 000 000,
or once every several hundred thousand years. The chance of the computer
breaking during this period is so so much higher, there is in this case no
point checking the malloc().

It is elementary. When you control the quality of a part, and there are
costs - here increased complexity of code, thus maintenance costs - the
quality should be high enough that your part is unlikely to the the point of
failure, but no higher.

As others have pointed out, if your main allocation is in a loop, the
probabilities have to be adjusted accordingly.

You might be interestwed in xmalloc(), on my website, which gets round this
problem of too much error-handling code which will never be executed. For
all I have said, there is also a case for making programs which are correct.

--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm


 
Reply With Quote
 
Army1987
Guest
Posts: n/a
 
      01-19-2008
Keith Thompson wrote:

> There's an old saying: Never check for an error condition you don't
> know how to handle.
>
> But if you can't figure out what to do, you can always just terminate
> the program. It's not necessarily the best thing you can do, but it's
> the second simplest, and it's almost certainly better than the
> simplest (ignoring the error).


Well, I don't usually check the result of a call such as
fprintf(stderr, "Can't frobnicate %s: %s\n", frob, strerror(errno)),
because I don't know what should I do if it failed, but I don't think that
just terminating the program would be a good idea (unless I were going to
terminate it right after the fprintf regardless of its success, that is).


--
Army1987 (Replace "NOSPAM" with "email")
 
Reply With Quote
 
Flash Gordon
Guest
Posts: n/a
 
      01-19-2008
Malcolm McLean wrote, On 19/01/08 10:47:
>
> "Marty James" <(E-Mail Removed)> wrote in message
>> Obviously, for tiny allocations like 20 bytes to strcpy a filename or
>> something, there's no point putting in a check on the return value of
>> malloc.
>>
>> OTOH, if you're allocating a gigabyte for a large array, this might
>> fail, so you should definitely check for a NULL return.
>>
>> So somewhere in between these extremes, there must be a point where you
>> stop ignoring malloc's return value, and start checking it.
>>
>> Where do people draw this line? I guess it depends on the likely system
>> the program will be deployed on, but are there any good rule-of-thumbs?
>>

> Yes.
> Imagine you've got 2GB installed and are allocating 20 bytes. The system
> is stressed and programs crash or terminate for lack of memory once a
> day. Any more than that, and no-one would tolerate it.
> So the chance the crash being caused by your allocation is 1/ 100 000
> 000, or once every several hundred thousand years. The chance of the
> computer breaking during this period is so so much higher, there is in
> this case no point checking the malloc().


This is incredibly bad advice. It has also been pointed out to Malcolm
in the past that it is incredibly bad advice.

I run out of memory on my company notebook with 2GB of RAM. I know
people run out of memory on servers with far more than 2GB of RAM. In
fact, I don't think I've had a month when some piece of SW has not
reported being out of memory and provided a recovery mechanism.

<snip>

> You might be interestwed in xmalloc(), on my website, which gets round
> this problem of too much error-handling code which will never be
> executed. For all I have said, there is also a case for making programs
> which are correct.


I would suggest looking very carefully at any malloc wrapper before
using it. You need to decide whether aborting on failure is appropriate
or some recovery strategy.
--
Flash Gordon
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
How to check whether malloc has allocated memory properly in case ifmalloc(0) can return valid pointer Shivanand Kadwadkar C Programming 83 01-08-2011 08:18 AM
Re: How to check whether malloc has allocated memory properly in caseif malloc(0) can return valid pointer Gene C Programming 0 12-20-2010 05:33 AM
When to check the return value of malloc sandeep C Programming 267 06-18-2010 06:11 PM
Proper way to check malloc return Billy Mays C Programming 37 06-09-2010 11:33 AM
what value does lack of return or empty "return;" return Greenhorn C Programming 15 03-06-2005 08:19 PM



Advertisments