Memory

[ranjeet.gupta]

Dear All,

Is it true that we can use dynamically-allocated memory after we free
it. ?
And if it is possible then how to make it sure that it can not be
used once we have freed
the dynamically allocated memory in our program.

Regards
Ranjeet

[Jack Klein]

On 20 Nov 2005 23:02:28 -0800, ra***********@gmail.com wrote in
comp.lang.c:

Dear All,

Is it true that we can use dynamically-allocated memory after we free
it. ?
No, it is not. Not if "we" want defined behavior.
And if it is possible then how to make it sure that it can not be
used once we have freed
the dynamically allocated memory in our program.

One way is use proper programming methods. Another, that works in
some cases, is to set pointers to NULL after freeing them, and always
checking them before using. But that doesn't work if there might be
copies of the original pointer around.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.contrib.andrew.cmu.edu/~a...FAQ-acllc.html

[Marc Boyer]

ra***********@gmail.com <ra***********@gmail.com> a écrit*:

Is it true that we can use dynamically-allocated memory after we free
it. ?
When you free a dynamically allocated memory, you tell to the
virtual machine 'I will no more use it, you can reuse it'.
But often, the virtual machine do not take it again ASAP.
So, often, you can free memory a reuse it. But sometime,
the virtual machine take it again as soon as you free it.

Did you expect you code to run successul often, sometime,
when the sun shines ?
And if it is possible then how to make it sure that it can not be
used once we have freed
the dynamically allocated memory in our program.

What is your problem ? Could you explain why you want to
do this ?

Marc Boyer

[Chris Dollin]

ra***********@gmail.com wrote:

Dear All,

Is it true that we can use dynamically-allocated memory after we free
it. ?
Only if you don't mind your program breaking in some unpredictable
way.

If `p` points to mallocated memory, after `free(p)` you are not allowed,
on pain of Undefined Behaviour, to do anything with the value of `p` or
any other pointer that pointed into the memory `p` pointed at.

The memory may no longer exist: it is permitted for the implementation
to return the address to the operating system, which might then unmap
the relevant piece of virtual address space and make the pointer value
invalid.

Even if it /does/ exist, its content may have been changed in arbitrary
ways: it may have been trampled on by housekeeping pointers, it may have
been cleared, it may have had a standard bitpattern sprayed onto it,
eg 0xdeadbeef, to make misuses easier to detect.
And if it is possible then how to make it sure that it can not be
used once we have freed
the dynamically allocated memory in our program.

Discipline, on the lines of "don't DO that".

--
Chris "another virtual machine" Dollin
missing tests don't fail.

[Blair Craft]

int *ptr = (int*)malloc(sizeof(int)); /* allocating memory: chunk a */
free(ptr); /* chunk a is freed, but _pointer_ ptr is still alive. */
ptr = NULL; /* done with it, no one can access that again, */

ra***********@gmail.com wrote:

Dear All,

Is it true that we can use dynamically-allocated memory after we free
it. ?
And if it is possible then how to make it sure that it can not be
used once we have freed
the dynamically allocated memory in our program.

Regards
Ranjeet

[Richard Heathfield]

ra***********@gmail.com said:

Dear All,

Is it true that we can use dynamically-allocated memory after we free
it. ?
Is it true that we can jump off a cliff whilst attached to a strong elastic
rope, get back on the cliff, take off the rope, and jump off the cliff
again?
And if it is possible then how to make it sure that it can not be
used once we have freed
the dynamically allocated memory in our program.

free(p);
p = NULL;

is a good start, but doesn't beat aliasing.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)

[Chris Dollin]

Blair Craft wrote:

int *ptr = (int*)malloc(sizeof(int)); /* allocating memory: chunk a */
Why cast?
free(ptr); /* chunk a is freed, but _pointer_ ptr is still alive. */
ptr = NULL; /* done with it, no one can access that again, */

In real code, between the malloc and the free the pointer may be copied
into other places. Nulling the pointer variable one has free'd doesn't
fix them, so thinking that it helps is ... iffy.

--
Chris "another virtual machine" Dollin
missing tests don't fail.

[carl]

Maybe the OP is worried about others reading the free'ed memory and is
looking for a 100% guaranteed method that any data in mem has gone.

Come on OP where have you gone?

[Randy Howard]

ra***********@gmail.com wrote
(in article
<11*********************@g14g2000cwa.googlegroups. com>):

Dear All,

Is it true that we can use dynamically-allocated memory after we free
it. ?
Not at all. It is true that a lot of people /try/ to do this,
and generally suffer the consequences. One very unfortunate
aspect of undefined behavior in C programs is that sometimes
code that is demonstrably broken will accidentally work anyway,
and the result of this seemingly unlikely result is to convince
programmers that they can get away with it. The truth is that
they just got very UNlucky and may not realize it until much
later.
And if it is possible then how to make it sure that it can not be
used once we have freed
the dynamically allocated memory in our program.

It's all but impossible to guarantee it won't happen through
some crutch method or language feature. however, you can code
to avoid it or perhaps eliminate it, if you are careful. There
is no foolproof method that I am aware of other than programmer
skill. Some folks always check for NULL before dereferencing a
pointer, and nevermind the performance consequences (I am one of
those). Some folks replace free() with a version to sets the
pointer to NULL afterward. That works in some, but not all
cases.

In any event, if someone told you it was okay to use it after
the fact, you owe it to the universe to convince them otherwise
before they spread such code around further. If you read it in
a book, please let us know the source.

--
Randy Howard (2reply remove FOOBAR)
"The power of accurate observation is called cynicism by those
who have not got it." - George Bernard Shaw

[Flash Gordon]

carl wrote:

Please provide context. Search this group for "google context" for
instructions on how to do this using Google.

Maybe the OP is worried about others reading the free'ed memory and is
looking for a 100% guaranteed method that any data in mem has gone.
If so, then the answer is highly platform specific and it may not be
possible.
Come on OP where have you gone?

No one knows.
--
Flash Gordon
Living in interesting times.
Although my email address says spam, it is real and I read it.

[Niklas Norrthon]

Blair Craft <yu****@postwebpro.com> writes:

int *ptr = (int*)malloc(sizeof(int)); /* allocating memory: chunk a */
free(ptr); /* chunk a is freed, but _pointer_ ptr is still alive. */
ptr = NULL; /* done with it, no one can access that again, */

or better:

#include <stdlib.h>

void foo(void)
{
int* ptr = malloc(sizeof *ptr);
/* do stuff with ptr */

free(ptr);
ptr = NULL; /* Not much harm, but doesn't really help much either */

/* do other stuff, otherwise the assignment above is totally pointless */
}

No need to cast void*. Some people here say don't the return value of
malloc, since it can hide the fact that stdlib.h isn't included. I have
another philosophy which is: don't cast anything at all if it isn't
really necessary... And if it is really necessary, you should first think
if there isn't an alternative way to accomplish the goal. The type casts
should only be used as a last resort.

About assigning NULL to freed pointers... It really doesn't help that
much, for two reasons:

* In my experience free statements are either often very near the end
of a function and the pointer varible will go out of scope soon enough
anyway.

* When memory from the free store (malloc and friends) there are usually
more than one pointer to the memory in question, and assigning NULL to
just one pointer won't affect all the other pointers, and it is these
more complicated situations that leads to buggy code anyway.

What really does help is a careful design where lifetime and ownership
of objects is specified, together with coding discipline.

/Niklas Norrthon