Does malloc() reuse addresses?

[avasilev]

Hi all,

my question is:

if i allocate some memory with malloc() and later free it (using
free()), is there a possibility that a consequent malloc() will
allocate memort at the same starting address and will return the same
pointer as the previous malloc(). I would like to have confirmation on
whether this is practically a concern when pointers are used to
uniquely identify data structure instances - like in this example:

int isInstanceValid (myStrict* inst)
{
int i;
for (i=0; i<instCount; ++i)
if (instances[i] == inst)
return 1;

return 0;
}

In this example, if an instance is freed, and a pointer to it becomes
non-valid, and later a new structure is allocated in the list, the
function will return that the pointer is valid, although it is actually
not the instance that was originally referred.

[Dann Corbit]

"avasilev" <al********@gma il.comwrote in message
news:11******** *************@h 48g2000cwc.goog legroups.com...

Hi all,

my question is:

if i allocate some memory with malloc() and later free it (using
free()), is there a possibility that a consequent malloc() will
allocate memort at the same starting address and will return the same
pointer as the previous malloc().

Yes. It happens all the time.

[Ben Pfaff]

"avasilev" <al********@gma il.comwrites:

if i allocate some memory with malloc() and later free it (using
free()), is there a possibility that a consequent malloc() will
allocate memort at the same starting address and will return the same
pointer as the previous malloc().

Yes.

I would like to have confirmation on whether this is
practically a concern when pointers are used to uniquely
identify data structure instances - like in this example:

It's an incorrect approach. Strictly speaking the behavior of
doing anything with a pointer to freed memory yields undefined
behavior.

You're better off using a counter to stamp each new structure
with a unique serial number and then comparing those unique
serial numbers.
--
"We put [the best] Assembler programmers in a little glass case in the hallway
near the Exit sign. The sign on the case says, `In case of optimization
problem, break glass.' Meanwhile, the problem solvers are busy doing their
work in languages most appropriate to the job at hand." --Richard Riehle

[goose]

avasilev wrote:

Hi all,

my question is:

if i allocate some memory with malloc() and later free it (using
free()), is there a possibility that a consequent malloc() will
allocate memort at the same starting address and will return the same
pointer as the previous malloc().

It might; you cannot depend on it though.

I would like to have confirmation on
whether this is practically a concern when pointers are used to
uniquely identify data structure instances - like in this example:

int isInstanceValid (myStrict* inst)
{
int i;
for (i=0; i<instCount; ++i)
if (instances[i] == inst)
return 1;

return 0;
}

In this example, if an instance is freed, and a pointer to it becomes
non-valid, and later a new structure is allocated in the list, the
function will return that the pointer is valid, although it is actually
not the instance that was originally referred.

yes

goose,

[Ancient_Hacker]

shouldnt be a problem, because if you're really keeping track of valid
pointers with that table, anytime you do a free() on a pointer you MUST
be removing that entry from the table.

[Barry Schwarz]

On 14 Jul 2006 11:48:15 -0700, "avasilev" <al********@gma il.com>
wrote:

>Hi all,

my question is:

if i allocate some memory with malloc() and later free it (using
free()), is there a possibility that a consequent malloc() will
allocate memort at the same starting address and will return the same
pointer as the previous malloc(). I would like to have confirmation on
whether this is practically a concern when pointers are used to

All in all a terrible plan.

Once an area of memory is freed, the pointer that was passed to free
becomes indeterminate so any attempt to evaluate that pointer invokes
undefined behavior.

Attempting to use the coincidence is extremely non-portable. Even if
the addresses should match up, how do you know that someone else did
not use (and free) the area in between the time you freed and
allocated it again. In a virtual memory system, even if the address
is the same it may be in a physically different portion of memory.
Some OSes reinitialize allocated memory (not necessarily to zero) as a
security precaution before allowing me to use it.
Remove del for email

[swengineer001]

avasilev wrote:

Hi all,

my question is:

if i allocate some memory with malloc() and later free it (using
free()), is there a possibility that a consequent malloc() will
allocate memort at the same starting address and will return the same
pointer as the previous malloc(). I would like to have confirmation on
whether this is practically a concern when pointers are used to
uniquely identify data structure instances - like in this example:

int isInstanceValid (myStrict* inst)
{
int i;
for (i=0; i<instCount; ++i)
if (instances[i] == inst)
return 1;

return 0;
}

In this example, if an instance is freed, and a pointer to it becomes
non-valid, and later a new structure is allocated in the list, the
function will return that the pointer is valid, although it is actually
not the instance that was originally referred.

If you are doing what you say with the instance array, why are you not
removing the pointer from the array when you free the element of the
list. Sounds like you might want to rethink your design a little.

[Dann Corbit]

"avasilev" <al********@gma il.comwrote in message
news:11******** *************@h 48g2000cwc.goog legroups.com...

What (exactly) are you trying to accomplish? Maybe if we knew what it was,
we could offer a suitable and portable method of accomplishing it.

[avasilev]

Ancient_Hacker wrote:

shouldnt be a problem, because if you're really keeping track of valid
pointers with that table, anytime you do a free() on a pointer you MUST
be removing that entry from the table.

Yes, but later I can allocate a new pointer and add it to the table, it
could happen to have the same value. Then a previously non-vaid pointer
becomes valid now.

[Dann Corbit]

"avasilev" <al********@gma il.comwrote in message
news:11******** *************@m 79g2000cwm.goog legroups.com...

>
Ancient_Hacker wrote:

>shouldnt be a problem, because if you're really keeping track of valid
pointers with that table, anytime you do a free() on a pointer you MUST
be removing that entry from the table.

Yes, but later I can allocate a new pointer and add it to the table, it
could happen to have the same value. Then a previously non-vaid pointer
becomes valid now.

But it does not necessarily even point to the same kind of object.

Some other malloc(), even inside a library call or DLL or some such thing,
may have allocated memory at that starting address. And if it has not been
allocated even testing to see what the value is invokes undefined behavior.

We can say for sure:

Broken plan, don't do it.

Really, really. Don't.