faqcatbafd.html

this is a mirrored site c-faq. thought might need offline

even before you multiply it by <TT>sizeof(double)</TT>.
If you
need to allocate
this much

memory,
you'll have to be careful.


If <TT>size_t</TT>
(the type accepted by <TT>malloc</TT>)
is a 32-bit type on your machine,
but <TT>int</TT> is 16 bits,
you might be able to get away with writing
<TT>300 * (300 * sizeof(double))</TT>
(see question <a href="faqcatee08.html?sec=expr#intoverflow1">3.14</a>).

Otherwise,
you'll have to break
your data structure
up into smaller chunks,
or use a 32-bit machine
or compiler,
or use
some nonstandard memory allocation functions.
See also
questions <a href="faqcatbafd.html?sec=malloc#sizetlong">7.15</a> and <a href="faqcatea63.html?sec=osdep#bigdatastr">19.23</a>.

<hr><hr><hr>
<a name="segment">
<h1>
comp.lang.c FAQ list
<font color=blue>&middot;</font>
<a href="../../malloc/segment.html"><!-- qtag -->Question 7.17</a>
</h1>
<p>
<font face=Helvetica size=8 color=blue><b>Q:</b></font>
I've got 8 meg of memory in my PC.
Why can I only seem to <TT>malloc</TT> 640K or so?
</p><p><hr>
<p>
<font face=Helvetica size=8 color=blue><b>A:</b></font>
Under the segmented architecture of PC compatibles,
it can be
difficult to use more than 640K
with any degree of transparency,
especially under MS-DOS.
See
also
question <a href="faqcatea63.html?sec=osdep#bigdatastr">19.23</a>.
<hr><hr><hr>
<a name="efficiency">
<h1>
comp.lang.c FAQ list
<font color=blue>&middot;</font>
<a href="../../malloc/efficiency.html"><!-- qtag -->Question 7.18</a>
</h1>
<p>
<font face=Helvetica size=8 color=blue><b>Q:</b></font>
My application depends heavily on
dynamic allocation of nodes for data structures,
and <TT>malloc</TT>/<TT>free</TT> overhead
is
becoming
a bottleneck.
What can
I do?
</p><p><hr>
<p>
<font face=Helvetica size=8 color=blue><b>A:</b></font>
One improvement,
which is particularly attractive if all nodes are the same size,
is to place unused nodes on your own free list,
rather than actually <TT>free</TT>ing them.
(This approach works well
when one kind of data structure dominates a program's memory use,
but it can cause as many problems as it solves
if so much memory is tied up in the
list of unused nodes
that it isn't available for other purposes.)
<hr><hr><hr>
<a name="crash">
<h1>
comp.lang.c FAQ list
<font color=blue>&middot;</font>
<a href="../../malloc/crash.html"><!-- qtag -->Question 7.19</a>
</h1>
<p>
<font face=Helvetica size=8 color=blue><b>Q:</b></font>
My program is crashing, apparently somewhere down inside
<TT>malloc</TT>,
but I can't see anything wrong with it.
Is there a bug in <TT>malloc</TT>?
</p><p><hr>
<p>
<font face=Helvetica size=8 color=blue><b>A:</b></font>
It is unfortunately very easy to corrupt
<TT>malloc</TT>'s internal data structures,
and the resulting problems can be
stubborn.
The most common source of problems is writing more to a
<TT>malloc</TT>'ed region than it was allocated to hold;
a particularly common bug is to <TT>malloc(strlen(s))</TT>
instead of <TT>strlen(s)&nbsp;+&nbsp;1</TT>.
<a href="../../malloc/morebugs.html" rel=subdocument>[footnote]</a>
Other problems may involve



using pointers to
memory that has been freed,
freeing pointers twice,
freeing pointers not
obtained from <TT>malloc</TT>,
<TT>free</TT>ing null pointers,
allocating 0-sized objects
(see question <a href="faqcat7d4b.html?sec=ansi#malloc0">11.26</a>),
or trying to <TT>realloc</TT> a null pointer
(see question
<a href="faqcatbafd.html?sec=malloc#reallocnull">7.30</a>).
(The last three--<TT>free</TT>ing null pointers,
allocating 0-sized objects,
and
<TT>realloc</TT>ing a null pointer--are sanctioned by the Standard,
though
older implementations often have problems.)



Consequences of
any of these errors
can show up
long after the actual mistake
and
in unrelated sections of code,
making diagnosis of the problem quite difficult.

</p><p>Most implementations of <TT>malloc</TT> are particularly vulnerable
to these problems because they store crucial
pieces of
internal
information directly adjacent to the blocks of memory
they return,
making them
easy prey for stray user pointers.
</p><p>See also questions
<a href="faqcatbafd.html?sec=malloc#sizetlong">7.15</a>,
<a href="faqcatbafd.html?sec=malloc#freesize">7.26</a>,
<a href="faqcat5e04.html?sec=strangeprob#segv">16.8</a>,
and
<a href="faqcatccbd.html?sec=resources#mallocdbg">18.2</a>.

<hr><hr><hr>
<a name="noscale">
<h1>
comp.lang.c FAQ list
<font color=blue>&middot;</font>
<a href="../../malloc/noscale.html"><!-- qtag -->Question 7.19b</a>
</h1>
<p>
<font face=Helvetica size=8 color=blue><b>Q:</b></font>
I'm dynamically allocating an array, like this:
<pre>
	int *iarray = (int *)malloc(nints);
</pre>
<TT>malloc</TT> isn't returning NULL,
but the code isn't working.
</p><p><hr>
<p>
<font face=Helvetica size=8 color=blue><b>A:</b></font>
<TT>malloc</TT>
is a low-level, typeless allocator.
It doesn't know
how you're going to use the memory;
all it does is to allocate
as many <em>bytes</em> of memory as you ask it.
Therefore
(except when you're allocating arrays of <TT>char</TT>)
you must
multiply by the size of the elements in the array you're allocating:
<pre>
	int *iarray = malloc(nints * sizeof(int));
</pre>
or
<pre>
	int *iarray = malloc(nints * sizeof(*iarray));
</pre>
(The latter fragment can be more reliable
if the type of <TT>iarray</TT> might change,
since there's only one place to change it.
Also, the casts have been removed;
see question <a href="faqcatbafd.html?sec=malloc#cast">7.7</a>.)
Compare question <a href="faqcatabdc.html?sec=ptrs#explscale">4.4</a>,
and see also question <a href="faqcatbafd.html?sec=malloc#sizeofchar">7.8</a>.
<hr><hr><hr>
<a name="useafterfree">
<h1>
comp.lang.c FAQ list
<font color=blue>&middot;</font>
<a href="../../malloc/useafterfree.html"><!-- qtag -->Question 7.20</a>
</h1>
<p>
<font face=Helvetica size=8 color=blue><b>Q:</b></font>
You can't use dynamically-allocated memory after you free it, can you?
</p><p><hr>
<p>
<font face=Helvetica size=8 color=blue><b>A:</b></font>
No.
Some early
documentation
for <TT>malloc</TT> stated that the contents of freed
memory
were
``left undisturbed,''
but
this ill-advised guarantee
was never
universal and is not required
by the C Standard.
</p><p>Few programmers would use the contents of freed memory
deliberately, but it is easy to do so accidentally.
Consider the following (correct) code for freeing a singly-linked
list:
<pre>
	struct list *listp, *nextp;
	for(listp = base; listp != NULL; listp = nextp) {
		nextp = listp-&gt;next;
		free(listp);
	}
</pre>
and notice what would happen

if the more-obvious loop iteration
expression <TT>listp&nbsp;=&nbsp;listp-&gt;next</TT>

were used,
without the temporary <TT>nextp</TT> pointer.
</p>




<p>References:

K&amp;R2 Sec. 7.8.5 p. 167
<br>
ISO Sec. 7.10.3
<br>
Rationale Sec. 4.10.3.2
<br>
H&amp;S Sec. 16.2 p. 387
<br>
CT&amp;P Sec. 7.10 p. 95
<hr><hr><hr>
<a name="ptrafterfree">
<h1>
comp.lang.c FAQ list
<font color=blue>&middot;</font>
<a href="../../malloc/ptrafterfree.html"><!-- qtag -->Question 7.21</a>
</h1>
<p>
<font face=Helvetica size=8 color=blue><b>Q:</b></font>
Why isn't a pointer
null
after calling
<TT>free</TT>?

<br>
How unsafe is it to use
(assign, compare)
a pointer value after it's been freed?
</p><p><hr>
<p>
<font face=Helvetica size=8 color=blue><b>A:</b></font>
When you call <TT>free</TT>,
the memory pointed to by the passed pointer is freed,
but the value of the pointer in the caller
probably
remains unchanged,
because
C's pass-by-value

semantics
mean that called functions
never permanently
change the values of their arguments.
(See also question <a href="faqcatabdc.html?sec=ptrs#passptrinit">4.8</a>.)
</p><p>A pointer
value
which has been freed is, strictly speaking, invalid,

and <em>any</em> use of it,
even if it is not dereferenced
(i.e. even if
the use of it is a
seemingly innocuous
assignment or comparison),
can theoretically lead to trouble.
(We
can probably assume that
as a quality of implementation issue,
most implementations will
not go out of their way
to generate exceptions
for innocuous uses of invalid
pointers,
but the Standard is clear
in saying that
nothing is guaranteed,
and




there are system architectures
for which
such
exceptions
would be quite natural.)
</p><p>When pointer variables
(or fields within structures)
are repeatedly allocated and freed within a program,
it is often useful to set them to NULL

immediately after freeing
them,
to explicitly record their state.
</p>

<p>References:

ISO Sec. 7.10.3
<br>
Rationale Sec. 3.2.2.3
<br></p>
<hr><hr><hr>
<a name="local">
<h1>
comp.lang.c FAQ list
<font color=blue>&middot;</font>
<a href="../../malloc/local.html"><!-- qtag -->Question 7.22</a>
</h1>
<p>
<font face=Helvetica size=8 color=blue><b>Q:</b></font>
When I call <TT>malloc</TT> to allocate memory for a
pointer which is local to a function,
do I have to explicitly <TT>free</TT> it?
</p><p><hr>
<p>
<font face=Helvetica size=8 color=blue><b>A:</b></font>
Yes.
Remember that a pointer is different from what it points to.
Local
variables
<a href="../../malloc/auto.html" rel=subdocument>[footnote]</a>
are deallocated when the function returns,
but in the case of a pointer variable,
this means that the pointer is deallocated,
<em>not</em> what it points to.
Memory allocated with <TT>malloc</TT> always persists
until you explicitly free it.
(If the only pointer to a block of <TT>malloc</TT>'ed memory 
is a local pointer,
and if that pointer disappears,
there will be no way to free
that block.)
In general,
for every call to <TT>malloc</TT>,
there should be a corresponding call to <TT>free</TT>.
<hr><hr><hr>
<a name="freeforall">
<h1>
comp.lang.c FAQ list
<font color=blue>&middot;</font>
<a href="../../malloc/freeforall.html"><!-- qtag -->Question 7.23</a>
</h1>
<p>
<font face=Helvetica size=8 color=blue><b>Q:</b></font>
I'm allocating structures which contain pointers to other
dynamically-allocated objects.
When I free
a structure,
do I
also
have to free each subsidiary pointer?
</p><p><hr>
<p>
<font face=Helvetica size=8 color=blue><b>A:</b></font>
Yes.
<TT>malloc</TT> knows nothing about structure declarations
or about the contents of allocated memory;

it especially does not know
whether allocated memory


contains pointers to other allocated memory.
In general,
you must arrange that each pointer returned from <TT>malloc</TT>
be individually passed to <TT>free</TT>,
exactly once
(if it is freed at all).
</p><p>
A good rule of thumb
is that for each call to <TT>malloc</TT> in a program,
you should be able to
point at
the call to <TT>free</TT>
which frees the memory allocated by that <TT>malloc</TT> call.

(In many cases,
you'll free blocks of memory in the reverse order you allocated them,
although this order is by no means required.)
</p><p>See also question <a href="faqcatbafd.html?sec=malloc#freeb4exit">7.24</a>.
<hr><hr><hr>
<a name="freeb4exit">
<h1>
comp.lang.c FAQ list
<font color=blue>&middot;</font>
<a href="../../malloc/freeb4exit.html"><!-- qtag -->Question 7.24</a>
</h1>
<p>
<font face=Helvetica size=8 color=blue><b>Q:</b></font>
Must I free allocated memory before the program exits?
</p><p><hr>
<p>
<font face=Helvetica size=8 color=blue><b>A:</b></font>
You shouldn't have to.
A real operating system
definitively reclaims
all memory
and other resources
when a program exits;
the system
cannot afford
to have
memory integrity
depend
on the whims of random programs.
(Strictly speaking,

it is not even <TT>free</TT>'s job
to return memory to the operating system;
see question <a href="faqcatbafd.html?sec=malloc#freetoOS">7.25</a>.)
Nevertheless, some personal computers

are said not to reliably recover memory
unless it was freed before exiting,
and all that can be inferred from the ANSI/ISO C Standard
is that this is a ``quality of implementation issue.''
</p><p>On the other hand,
the C library <TT>free</TT> function rarely returns memory back
to the operating system
(see question <a href="faqcatbafd.html?sec=malloc#freetoOS">7.25</a>),
so calling <TT>free</TT> probably isn't the way to guarantee
that an exiting program's memory is recovered by the system, anyway.
</p><p>In any case,
it can be considered good practice to explicitly free all
memory--for
example,
in case the program is ever rewritten
to perform its main task more than once
(perhaps under a Graphical User Interface).
<a href="../../malloc/prleak.html" rel=subdocument>[footnote]</a>
On the other hand,



there are programs
(such as interpreters)
that don't know what
memory
they're done with
(i.e. what memory could be freed)
until it's time to exit,
and since all memory should be released at exit,
it would be a needless,
potentially
expensive, and
error-prone exercise
for the program to explicitly free all of it.
</p><p>Additional links:
<a href="faqcatbafd.html?sec=malloc#freeb4exit2">further explanation</a>
</p>
<p>References:

ISO Sec. 7.10.3.2
<hr><hr><hr>
<a name="freetoOS">
<h1>
comp.lang.c FAQ list
<font color=blue>&middot;</font>
<a href="../../malloc/freetoOS.html"><!-- qtag -->Question 7.25</a>
</h1>
<p>
<font face=Helvetica size=8 color=blue><b>Q:</b></font>
I have a program which <TT>malloc</TT>s
and later
<TT>free</TT>s a lot
of memory,
but
I can see from the operating system
that
memory usage
doesn't
actually
go back down.
</p><p><hr>
<p>
<font face=Helvetica size=8 color=blue><b>A:</b></font>
Most
implementations of <TT>malloc</TT>/<TT>free</TT> do not return <TT>free</TT>d memory
to the operating system,
but merely make it available
for future <TT>malloc</TT> calls