Malloc and free questions - learner questions

[Christopher Layne]

Now I've outsourced all my processing to China, I've got over a billion
people slaving away for me.
So I can ask them to give an ascii character, which they can't read being
Chinese, to a thousand people, a thousand thousand times. We have the
inevitable occasional hitch, and downtime is more than one in a million
runs.

China apparently has around 1.4B people currently. Pretty soon they're going
to overflow a signed long.

 

[CBFalconer]

What's wrong with alloca() ?

It doesn't exist in ISO standard C, which is the subject here.
Thus it is off-topic, and has unknown properties.

--
Some informative links:
< <http://www.geocities.com/nnqweb/>
<http://www.catb.org/~esr/faqs/smart-questions.html>
<http://www.caliburn.nl/topposting.html>
<http://www.netmeister.org/news/learn2quote.html>
<http://cfaj.freeshell.org/google/>

 

[Richard Heathfield]

Malcolm said:

Now I've outsourced all my processing to China, I've got over a billion
people slaving away for me.
So I can ask them to give an ascii character, which they can't read being
Chinese, to a thousand people, a thousand thousand times. We have the
inevitable occasional hitch, and downtime is more than one in a million
runs.

What has this to do with malloc? Your analogy escapes me. Note that your
claim is that malloc /never/ fails, not that it rarely fails, for small
allocations.

 

[Christopher Layne]

It doesn't exist in ISO standard C, which is the subject here.
Thus it is off-topic, and has unknown properties.

Also, even if you did acknowledge it's presence, direct from a Linux man page:

BUGS:
The alloca function is machine and compiler dependent. On many systems
its implementation is buggy. Its use is discouraged.

On many systems alloca cannot be used inside the list of arguments of
a function call, because the stack space reserved by alloca would appear on
the stack in the middle of the space for the function arguments.


Even Solaris manpage:

WARNINGS
The alloca() function is machine-, compiler-, and most of
all, system-dependent. Its use is strongly discouraged.

 

[Mike Wahler]

You must always check whether malloc() succeeded or not by examining
its return value: if 0 (NULL) it failed. If malloc() succeeds, then
the size of the memory allocated is exactly what you specified.

[...]

Not necessarily, memory allocated can be more than requested.

As far as the caller is concerned, that's none of their concern, however.
Not
saying it isn't something to consider, but it's not to be taken advantage
of.

Maybe not 'to be taken advantage of', but surely 'to be considered',
i.e. looking at a system's reporting of available memory before and
after a 'malloc()' call, the numbers may not always add up to one's
expectations.

-Mike

 

[Christopher Layne]

Maybe not 'to be taken advantage of', but surely 'to be considered',
i.e. looking at a system's reporting of available memory before and
after a 'malloc()' call, the numbers may not always add up to one's
expectations.

-Mike

It won't even be close to accurate for one. The reason I mentioned it to be
considered is from the standpoint of "real" memory footprint when dealing
with 1000s or 100s of 1000s of dynamically allocated objects and how that may
play into things with lower layer malloc management/needs.

 

[Malcolm]

Malcolm said:


What has this to do with malloc? Your analogy escapes me. Note that your
claim is that malloc /never/ fails, not that it rarely fails, for small
allocations.

As I said, I've got a billion Chinese people working for me.
So if I want, I can order them all to stand in a line, holding white boards
with ASCII characters written on them, which they can't read of course, any
more than I can read Chinese.
However if I do that, there will be no-one to work the paddy fields. It will
be terrible. People dropping dead of starvation all over the place. And my
results will slow down.

So in fact, as soon as a rice shortage develops, what I do is I say "OK, ten
million of you, drop those boards and let them be picked up later. Go to the
fields and pick rice".
So they do. So it never happens that my allocations fail - I can always get
a few from the paddy fields in a tight spot.

 

[Richard Heathfield]

Malcolm said:

As I said, I've got a billion Chinese people working for me.
So if I want, I can order them all to stand in a line, holding white
boards with ASCII characters written on them, which they can't read of
course, any more than I can read Chinese.
However if I do that, there will be no-one to work the paddy fields. It
will be terrible. People dropping dead of starvation all over the place.
And my results will slow down.

So in fact, as soon as a rice shortage develops, what I do is I say "OK,
ten million of you, drop those boards and let them be picked up later. Go
to the fields and pick rice".
So they do. So it never happens that my allocations fail - I can always
get a few from the paddy fields in a tight spot.

As I said, what has this to do with malloc? Your analogy still escapes me.

 

[Gordon Burditt]

Nowadays malloc() never fails, at least for small allocations.

Nowadays it may take longer for a daemon with a memory leak (even
if it's only leaking a couple hundred bytes at a time) to run the
system out of swap space, at least for systems with small (e.g. <
512TB) swap partitions. But it will happen eventually.

The computer is far more likely to break than to fail to deliver a kilobyte
of memory.

However the standard says it can fail, so to be strictly correct you need to
check it.

In the real world, you can run out of memory. I never thought that
an instance of a mail server process intended to handle one incoming
connection and then exit would run the system out of swap space,
even with a small per-email-message memory leak. It did. It turns
out that when it rejects SPAM, it leaked copies of the headers
(about 2K per message). Now add a persistent spammer who tried
sending a quarter million spams (not an exaggeration: I counted log
entries) in one connection over a period of a day and a half.

 

[Christopher Layne]

Nowadays it may take longer for a daemon with a memory leak (even
if it's only leaking a couple hundred bytes at a time) to run the
system out of swap space, at least for systems with small (e.g. <
512TB) swap partitions. But it will happen eventually.

< 512TB swap is SMALL?

Who even uses a system with 1 TB of swap?

 

[Bill Pursell]

Bill Pursell said:


Blech. One might not mind doing the void * tango for /one/ pointer, but the
whole point of my_malloc is to take a whole set of them. Isn't the solution
clumsier than the problem it's trying to fix?

I agree that's is not completely elegant, but I think it's slightly
less clumsy than the alternative. It's certainly not ideal, but
it's not too bad to use it like this:

T * new_t(void)
{
T *t;
void *tmp[3];
if (my_malloc(tmp, sizeof *t, tmp+1, sizeof *t->a, tmp+2,
sizeof *t->b, NULL) == 0) {
t = tmp[0];
t->a = tmp[1];
t->b = tmp[2];
}
else
t = NULL;
return t;
}