Memory Allocation for Dynamic Alloccation

[Sandeep Chikkerur]

Hi,

If the entire heap memory for dynamic allocation is not available,
does the compiler always return NULL ?

eg:

char *s;
s = (char *)malloc(...);

During execution, if the entire memory reserved for dynamic allocation
is not available, what would the OS return? Does it use ny mechanism
to still allocate the memory?

Rgds
Sandeep

 

[Joona I Palaste]

Hi,

If the entire heap memory for dynamic allocation is not available,
does the compiler always return NULL ?

What is "heap memory"? C knows of no such thing.

eg:

char *s;
s = (char *)malloc(...);

Can't you afford stdlib.h?

During execution, if the entire memory reserved for dynamic allocation
is not available, what would the OS return? Does it use ny mechanism
to still allocate the memory?

If the OS can't allocate at least as much memory as you asked for in
the malloc() call, it must return NULL. It might use some mechanism to
allocate some other memory "behind the scenes", but it must still
return NULL from malloc(). Allocating other memory "behind the scenes"
would be a bit pointless (I'm sure Dan Pop will now tell me it
sometimes isn't), but the standard allows such behaviour.

--
/-- Joona Palaste ([email protected]) ------------- Finland --------\
\-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
"The day Microsoft makes something that doesn't suck is probably the day they
start making vacuum cleaners."
- Ernst Jan Plugge

 

[Richard Bos]

If the entire heap memory for dynamic allocation is not available,
does the compiler always return NULL ?

No. It returns a null pointer, not a compile-time constant.

char *s;
s = (char *)malloc(...);

You do not need the cast, and if you think you do, you probably forgot
some headers.

During execution, if the entire memory reserved for dynamic allocation
is not available, what would the OS return?

The OS has nothing to do with it. The C implementation uses _some_
mechanism to get your allocated memory for you. The Standard doesn't
specify what mechanism should be used, and if the implementation wants
to ask the OS for memory it can do so, but from the POV of the C
program, it simply gets some allocated memory, no matter whence.

And yes, when this allocated memory store is _entirely_ depleted,
malloc() must return a null pointer.

Does it use ny mechanism to still allocate the memory?

How can it? The _entire_ memory reserved for allocation is full; do you
know of any mechanism that allows a CPU to go to the store, buy some
memory chips or swap disks, and mount them inside its case on the fly?

Richard

 

[Gordon Burditt]

And yes, when this allocated memory store is _entirely_ depleted,

malloc() must return a null pointer.

What's a ny? A large city on the east coast of the USA?

How can it? The _entire_ memory reserved for allocation is full; do you
know of any mechanism that allows a CPU to go to the store, buy some
memory chips or swap disks, and mount them inside its case on the fly?

If the CPU can buy the memory on Ebay and pay to get it installed,
or buy/rent more disk space on a remote server and then swap/page
to it, then the available memory ISN'T entirely depleted, and
malloc() can return a pointer to part of it. This call to malloc()
may take a while to complete, though. So will any mechanism that
involves swapping to paper tape, punch cards, or stone tablets.


Gordon L. Burditt

 

[Peter Ammon]

Hi,

If the entire heap memory for dynamic allocation is not available,
does the compiler always return NULL ?

This is how it must behave according to the C standard. However, I am
told that Linux behaves differently, in a possibly non-conforming
manner: the memory is not actually allocated until you try to use it, at
which point there may no longer be free memory left. So you may get a
non-null pointer back from malloc() that crashes when you try to use it
under Linux and possibly other OSes.

[...]

-Peter

 

[Alan Balmer]

How can it? The _entire_ memory reserved for allocation is full; do you
know of any mechanism that allows a CPU to go to the store, buy some
memory chips or swap disks, and mount them inside its case on the fly?

I can imagine memory being sold the way larger multi-cpu systems are -
pay more and they use software to turn on more cpus.

 

[Michael Wojcik]

This is how it must behave according to the C standard. However, I am
told that Linux behaves differently, in a possibly non-conforming
manner: the memory is not actually allocated until you try to use it, at
which point there may no longer be free memory left.

There was a thread about lazy allocation here not long ago, and the
consensus appears to be that lazy allocation is a QoI issue (and a
debatable one at that), not a conformance one. See [1] (downthread
a ways). (I don't know about typical Linux implementations, but AIX,
for example, provides a lazy allocator by default, though there are
ways to select a strict allocator and require backing store for all
allocated memory.)

Consider that allocated memory may become unavailable after allocation,
even without lazy allocation, eg due to hardware failure in the portion
of the disk used for paging space in a virtual-memory OS. A non-null
return from malloc should not be interpreted as a guarantee from the OS
that the program will never run into difficulties due to accessing that
memory, just as a non-null return from fopen does not guarantee that
the program will always be able to perform I/O successfully on that
file.


1. http://groups.google.com/[email protected]&rnum=1

--
Michael Wojcik (e-mail address removed)

Pocket #9: A complete "artificial glen" with rocks, and artificial moon,
and forester's station. Excellent for achieving the effect of the
sublime without going out-of-doors. -- Joe Green