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

 
 
sandeep
Guest
Posts: n/a
 
      05-15-2010
Hello friends~~

Think about malloc.

Obviously, for tiny allocations like 20 bytes to strcpy a filename,
there's no point putting in a check on the return value of malloc... if
there is so little memory then stack allocations will also be failing and
your program will be dead.

Whereas, if you're allocating a gigabyte for a large array, this might
easily fail, so you should definitely check for a NULL return.

So somewhere in between there must be a point where you stop ignoring the
return value, and start checking it. Where do you draw this line? It must
depend on whether you will deploy to a low memory or high memory
environment... but is there a good rule?

Regards~~
 
Reply With Quote
 
 
 
 
Tim Harig
Guest
Posts: n/a
 
      05-15-2010
On 2010-05-15, sandeep <(E-Mail Removed)> wrote:
> Obviously, for tiny allocations like 20 bytes to strcpy a filename,
> there's no point putting in a check on the return value of malloc... if
> there is so little memory then stack allocations will also be failing and
> your program will be dead.


Always check for error conditions. The heap and stack use different areas
of memory; and, the stack memory is likely already be allocated. Therefore, it
is quite possible that you still have stack memory left while you cannot
request any more from the heap.
 
Reply With Quote
 
 
 
 
Tim Harig
Guest
Posts: n/a
 
      05-15-2010
On 2010-05-15, Tim Harig <(E-Mail Removed)> wrote:
> On 2010-05-15, sandeep <(E-Mail Removed)> wrote:
>> Obviously, for tiny allocations like 20 bytes to strcpy a filename,
>> there's no point putting in a check on the return value of malloc... if
>> there is so little memory then stack allocations will also be failing and
>> your program will be dead.

>
> Always check for error conditions. The heap and stack use different areas
> of memory; and, the stack memory is likely already be allocated. Therefore, it
> is quite possible that you still have stack memory left while you cannot
> request any more from the heap.


BTW, if you are wondering how you can possibly go on without any more heap
memory, most users prefer a message telling them that you cannot perform an
operation because of insufficient memory then simply having the program
crash with a segfault. It also makes your troubleshooting and debugging
much easier.
 
Reply With Quote
 
bart.c
Guest
Posts: n/a
 
      05-15-2010

"sandeep" <(E-Mail Removed)> wrote in message
news:hsmqib$c10$(E-Mail Removed)...
> Hello friends~~
>
> Think about malloc.
>
> Obviously, for tiny allocations like 20 bytes to strcpy a filename,
> there's no point putting in a check on the return value of malloc... if
> there is so little memory then stack allocations will also be failing and
> your program will be dead.
>
> Whereas, if you're allocating a gigabyte for a large array, this might
> easily fail, so you should definitely check for a NULL return.
>
> So somewhere in between there must be a point where you stop ignoring the
> return value, and start checking it. Where do you draw this line? It must
> depend on whether you will deploy to a low memory or high memory
> environment... but is there a good rule?


For a proper application, especially to be run by someone else on their own
machine, then you should check allocations of any size (and have the
machinery in place to deal with failures sensibly).

For anything else, where you don't expect a failure, or it is not a big
deal, then use a wrapper function around malloc(). That wrapper will itself
check, and abort in the unlikely event of a memory failure. But it means you
don't have to bother with it in your main code.

It is also possible to just call malloc() and assume it has worked. Your
experience will tell you when you can get away with that. But only do that
with your own programs...

--
Bartc

 
Reply With Quote
 
Eric Sosman
Guest
Posts: n/a
 
      05-15-2010
On 5/15/2010 2:52 PM, sandeep wrote:
> Hello friends~~
>
> Think about malloc.
>
> Obviously, for tiny allocations like 20 bytes to strcpy a filename,
> there's no point putting in a check on the return value of malloc...


Obviously, you are ignorant of the Sixth Commandment. The text
of all ten Commandments, along with learned commentary can be found
at <http://www.lysator.liu.se/c/ten-commandments.html>.

> if
> there is so little memory then stack allocations will also be failing and
> your program will be dead.


On many systems -- maybe even on most -- memory for auto variables
and memory for malloc() is drawn from different "pools," and one can
run out while the other still has ample space.

> Whereas, if you're allocating a gigabyte for a large array, this might
> easily fail, so you should definitely check for a NULL return.


Yes, you should definitely check for a NULL return.

> So somewhere in between there must be a point where you stop ignoring the
> return value, and start checking it. Where do you draw this line? It must
> depend on whether you will deploy to a low memory or high memory
> environment... but is there a good rule?


Yes. You can get away with not checking the value returned by
malloc(N) if N is evenly divisible by all prime numbers (you only
need to test divisors up to sqrt((size_t)-1); any larger primes can
be ignored). For all other values of N, you must check the value
returned by malloc() -- and similarly for calloc() and realloc(),
of course.

--
Eric Sosman
http://www.velocityreviews.com/forums/(E-Mail Removed)lid
 
Reply With Quote
 
Seebs
Guest
Posts: n/a
 
      05-15-2010
On 2010-05-15, sandeep <(E-Mail Removed)> wrote:
> Hello friends~~
>
> Think about malloc.
>
> Obviously, for tiny allocations like 20 bytes to strcpy a filename,
> there's no point putting in a check on the return value of malloc... if
> there is so little memory then stack allocations will also be failing and
> your program will be dead.


Not necessarily true -- there is no reason to assume that "stack allocations"
and malloc() are using the same pool of memory. Furthermore, it's quite
possible for malloc to fail, not because 20 bytes aren't available, but
because it can't get enough space for the 20 bytes plus overhead.

> So somewhere in between there must be a point where you stop ignoring the
> return value, and start checking it. Where do you draw this line? It must
> depend on whether you will deploy to a low memory or high memory
> environment... but is there a good rule?


There is -- ALWAYS check.

-s
--
Copyright 2010, all wrongs reversed. Peter Seebach / (E-Mail Removed)
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
 
Reply With Quote
 
Richard Bos
Guest
Posts: n/a
 
      05-15-2010
sandeep <(E-Mail Removed)> wrote:

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


Wrong.

Richard
 
Reply With Quote
 
Gene
Guest
Posts: n/a
 
      05-15-2010
On May 15, 2:52*pm, sandeep <(E-Mail Removed)> wrote:
> Hello friends~~
>
> Think about malloc.
>
> Obviously, for tiny allocations like 20 bytes to strcpy a filename,
> there's no point putting in a check on the return value of malloc... if
> there is so little memory then stack allocations will also be failing and
> your program will be dead.
>
> Whereas, if you're allocating a gigabyte for a large array, this might
> easily fail, so you should definitely check for a NULL return.
>
> So somewhere in between there must be a point where you stop ignoring the
> return value, and start checking it. Where do you draw this line? It must
> depend on whether you will deploy to a low memory or high memory
> environment... but is there a good rule?
>
> Regards~~


As has been said, in production code, you always check. However this
does not mean you have to code a specific check for each allocation.

The usual is to define a wrapper around malloc() that checks for null
returns and deals with them through a callback mechanism where
presumably resources are freed so the allocation can succeed and/or a
longjmp() that terminates the application gracefully.

One thing that hasn't been mentioned about heap storage is
fragmentation. Even if you are allocating 20 bytes, malloc() can
still fail with (theoretically) 19/20 = 95% memory free. The
improbable, the moral is that when heap allocation fails, an app keep
running by compacting the heap. If you aren't checking each
allocation, this doesn't work.



 
Reply With Quote
 
sandeep
Guest
Posts: n/a
 
      05-15-2010
bart.c writes:

> "sandeep" <(E-Mail Removed)> wrote in message
> news:hsmqib$c10$(E-Mail Removed)...
>> Hello friends~~
>>
>> Think about malloc.
>>
>> Obviously, for tiny allocations like 20 bytes to strcpy a filename,
>> there's no point putting in a check on the return value of malloc... if
>> there is so little memory then stack allocations will also be failing
>> and your program will be dead.
>>
>> Whereas, if you're allocating a gigabyte for a large array, this might
>> easily fail, so you should definitely check for a NULL return.
>>
>> So somewhere in between there must be a point where you stop ignoring
>> the return value, and start checking it. Where do you draw this line?
>> It must depend on whether you will deploy to a low memory or high
>> memory environment... but is there a good rule?

>
> For a proper application, especially to be run by someone else on their
> own machine, then you should check allocations of any size (and have the
> machinery in place to deal with failures sensibly).
>
> For anything else, where you don't expect a failure, or it is not a big
> deal, then use a wrapper function around malloc(). That wrapper will
> itself check, and abort in the unlikely event of a memory failure. But
> it means you don't have to bother with it in your main code.


This is a good idea. I have just made a clever macro to do this - not as
easy as it seems due to void use problems and need for a temporary.

static void* __p;
#define safeMalloc(x) ((__p=malloc(x))?__p:\
(exit(printf("unspecified error")),(void*)0))
 
Reply With Quote
 
Seebs
Guest
Posts: n/a
 
      05-15-2010
On 2010-05-15, sandeep <(E-Mail Removed)> wrote:
> This is a good idea. I have just made a clever macro to do this - not as
> easy as it seems due to void use problems and need for a temporary.


> static void* __p;
> #define safeMalloc(x) ((__p=malloc(x))?__p:\
> (exit(printf("unspecified error")),(void*)0))


Write a function, not a macro, it'll be easier to make effective use of.

Also.

1. Use fprintf(stderr,...) for error messages.
2. Terminate error messages with newlines.
3. Why the *HELL* would you use "unspecified error" as the error message
when you have ABSOLUTE CERTAINTY of what the error is? Why not:
fprintf(stderr, "Allocation of %ld bytes failed.\n", (unsigned long) x);

The first two are comprehensible mistakes. The third isn't. Under what
POSSIBLE circumstances could you think that "unspecified error" is a better
diagnostic than something that in some way indicates that a memory allocation
failed?

I really don't understand this one. Please try to explain your reasoning,
because I regularly encounter software that fails with messages like these,
and I've always assumed it was something people did out of active malice --
they hate their users and want the users to suffer. If there is any other
possible reason to, given total certainty of what the problem is, refuse
to hint at it, I do not know what it is.

-s
--
Copyright 2010, all wrongs reversed. Peter Seebach / (E-Mail Removed)
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
 
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
Proper way to check malloc return Billy Mays C Programming 37 06-09-2010 11:33 AM
When to check the return value of malloc Marty James C Programming 333 02-06-2008 11:10 PM
what value does lack of return or empty "return;" return Greenhorn C Programming 15 03-06-2005 08:19 PM



Advertisments