about MALLOC

[nrk]

Overhead? Could you, please, elaborate?

Joona's code will call free() every time. Alexandre's code will call
free() every time - epsilon.

Joona's code will not check the pointer against NULL everytime. Alexandre's
code will. Given that it is rather rare to run into situations where
malloc returns NULL, makes eminent sense to avoid the unnecessary check and
optimize the most common case.

-nrk.

 

[Grumble]

Joona's code will not check the pointer against NULL everytime. Alexandre's
code will. Given that it is rather rare to run into situations where
malloc returns NULL, makes eminent sense to avoid the unnecessary check and
optimize the most common case.

Someone snipped too much context.

Joona wrote:

char *foo = malloc(6);
if (foo)
strcpy(foo, "Hello");
free(foo);

How can you say that Joona's code will not check the pointer's value?

This is not a free(p) vs if (p) free(p) issue. The test must be done.

 

[Joona I Palaste]

Joona's code will not check the pointer against NULL everytime. Alexandre's
code will. Given that it is rather rare to run into situations where
malloc returns NULL, makes eminent sense to avoid the unnecessary check and
optimize the most common case.

Grumble is right, my code *will* check against NULL every time. It is
also true that there is *more* overhead in my code than in Alexandre's.

--
/-- Joona Palaste ([email protected]) ------------- Finland --------\
\-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
"When a man talks dirty to a woman, that's sexual harassment. When a woman talks
dirty to a man, that's 14.99 per minute + local telephone charges!"
- Ruben Stiller

 

[Dan Pop]

I didn't find any function named "MALLOC" in my implementation (gcc...).
There is a "malloc" function, but since C is case-sensitive, it cannot
be the same !-)

When it comes to external identifiers, C89 is not necessarily case
sensitive ;-)

Dan

 

[Dan Pop]

I got to thinking... why are we all so smugly saying *both* "It's
malloc. not MALLOC" *and* "Read your friendly textbook" to Caroline?
What if she *knows* what malloc is, but has *really* encountered
*MALLOC* and doesn't know what it is? (Anymore than we do, because
it's not standard C.)

In this case, she would have worded her question differently.

Dan

 

[Randy Howard]

Given that it is rather rare to run into situations where
malloc returns NULL, makes eminent sense to avoid the unnecessary
check and optimize the most common case.

-nrk.

You've got to be kidding. malloc() can indeed fail, and often,
particularly in algorithms that increase the size of the malloc
call (or realloc) exponentially for large data structures. Consider
what happens when you try to make a > 2GB malloc() request on a 32-bit
system for a moment. I've seen it happen.

Further, not all OS's support VM in a way that you always get the
memory you need from a malloc call on a heavily loaded system, even
for smaller amounts.

You *really* shouldn't be believing, or dishing out this type of
advice.

 

[Robert Bachmann]

What is MALLOC exactly?
Where is it used?
Can someone please provide me with descriptive examples?

http://www.rocketaware.com/man/man3/malloc.3.htm
possibly provides a good overview.

Regards,
Robert

 

[Mark McIntyre]

Overhead? Could you, please, elaborate?

Joona's code will call free() every time. Alexandre's code will call
free() every time - epsilon.

One of them performs an extra comparison.

 

[Mark McIntyre]

Someone snipped too much context.

the context of my reply is this one:

Just because 'free' gracefully handles NULL, it doesn't mean
that this "functionality" should be always exercised.

which I took to mean "just because free() gracefully handles NULL,
doesn't mean you should always rely on this funcitonality".

This is not a free(p) vs if (p) free(p) issue.

that certainly wasn't clear to me.

The test must be done.

in the case of actually using foo, yup.

 

[nrk]

You've got to be kidding. malloc() can indeed fail, and often,
particularly in algorithms that increase the size of the malloc
call (or realloc) exponentially for large data structures. Consider
what happens when you try to make a > 2GB malloc() request on a 32-bit
system for a moment. I've seen it happen.

Further, not all OS's support VM in a way that you always get the
memory you need from a malloc call on a heavily loaded system, even
for smaller amounts.

You *really* shouldn't be believing, or dishing out this type of
advice.

Sorry, my mistake (but not the one you think I made). Too much context was
snipped out, and like the idiot that I am I didn't refer upthread to
refresh the context... I was talking about checking the pointer just before
calling free as in:
if ( ptr ) free(ptr);
which as you know is quite wasteful. Of course, this wasn't what was being
done in the code in question. I am in total agreement with your opinion on
checking malloc's return value.

-nrk.

 

[Alex]

Randy Howard wrote:

Sorry, my mistake (but not the one you think I made). Too much context was
snipped out, and like the idiot that I am I didn't refer upthread to
refresh the context... I was talking about checking the pointer just before
calling free as in:
if ( ptr ) free(ptr);
which as you know is quite wasteful. Of course, this wasn't what was being

This is *never* necessary. It is arguably stylistically
better to free the pointer in the context in which it is
known to be valid, if such context is available. If it is
not, there is absolutely no need to introduce the check
specifically for 'free'.

Alex

 

[Randy Howard]

Sorry, my mistake (but not the one you think I made). Too much context was
snipped out, and like the idiot that I am I didn't refer upthread to
refresh the context... I was talking about checking the pointer just before
calling free as in:
if ( ptr ) free(ptr);
which as you know is quite wasteful.

Sorry, I could have read more of the context as well.