realloc() implicit free() ?

[Walter Roberson]

If realloc() finds it necessary to move the memory block, then
does it free() the previously allocated block?

The C89 standard has some reference to undefined behaviour if one
realloc()'s memory that was freed by realloc(), but the only way
explicitly mentioned in the C89 standard to free memory via realloc()
is to realloc() it down to 0 bytes.

I had always assumed it would automatically free the previous memory,
but is the behaviour instead undefined [or defined as not happening] ?
--
"This was a Golden Age, a time of high adventure, rich living and
hard dying... but nobody thought so." -- Alfred Bester, TSMD

[Chris Croughton]

On Mon, 23 May 2005 20:46:49 -0400, Eric Sosman
<es*****@acm-dot-org.invalid> wrote:

Chris Croughton wrote:

Is there anything which says that alignments are always on a power of 2?
Not to my knowledge.

If not, then malloc() could have to be very wasteful. Imagine a system
(the DS9011, say) where a byte is 11 bits and the sizes (and alignments)
in bytes are:

Type Alignment
char 1
short 2
int 3
long 5
long long 7

and assigning

Thus malloc() would have to return an area aligned to at least 2*3*5*7
which is 210 bytes, even for malloc(1).

ITYM "1*2*3*5*7. " Two marks off for bad penmanship.

Last I heard multiplying by 1 didn't change the result <g>. I certainly
didn't mean "1*2*3*5*7. ", since that would have placed a full stop (or a
'period' as the Americans call it) in the sentence where I did not want
it.

However, I have no idea why the line saying just "and assigning" was in
there...

Perhaps it is needed a version of malloc() which takes the size of the
base object as well as the number of them, so

type *p = nmalloc(sizeof( *p), num);

That could look up the size and work out the alignment (if it was not a
basic type then it could just use the sizeof value, since the alignment
for that type must be that value or a submultiple of it).

About a decade ago this question arose with respect to
calloc(), and the eventual conclusion was that calloc() had to
be "oblivious" to the significance of its two operands. That
is, calloc(2,8) and calloc(8,2) had to satisfy exactly the same
alignment constraints: the former could not legitimately decide
that only 2-byte alignment was required.

Backwards compatibility? That's why I used a non-standard function
nmalloc(), because calloc() already has defined behaviour which is not
compatible with a version which limits the required alignment.
Mind you, much heated discussion preceded the conclusion,
and it is not certain that all the discussors agreed thereto.
"A man convinced against his will is of the same opinion still."

Indeed. A majority is not always right...

Chris C

[Richard Bos]

SM Ryan <wy*****@tang o-sierra-oscar-foxtrot-tango.fake.org> wrote:

# > # ># If realloc() finds it necessary to move the memory block, then
# > # ># does it free() the previously allocated block?

# Nope; that's probably why the OP wanted to know whether realloc() frees
# the block it is passed. If it didn't, and could leak, one could still
# implement a version which doesn't leak using malloc() and free(). From
# the answers to the OP one can conclude that this isn't necessary; but
# the question makes sense.

Some day you'll learn about modular programming.
And some day, you'll learn to post. Perhaps some day, much later, you'll
even learn to read. Modular programming is not relevant to the OP's
question.
Most malloc libraries promise

What libraries promise is immaterial. The question was not about what
they are likely to do, but about what they _must_ do.

Richard

[Walter Roberson]

In article <11************ *@corp.supernew s.com>,
SM Ryan <wy*****@tang o-sierra-oscar-foxtrot-tango.fake.org> wrote:
:Some day you'll learn about modular programming. Most malloc libraries promise
:not to leak if you match allocates and free properly.

Ah, could you provide a reference in the C89 standard that indicates
that malloc()/ free()/ realloc() are required to be "modular programming"?
I seem to have overlooked that section, and my copy of C89
does not index "modular", "structured " or "procedural " anywhere in
the main index nor the index of the Rationale.

:It suffices to know the interface and that you cannot trust the input pointer
:to realloc, but rather the output pointer (whether they differ or no).

Could you point me to the portion of C89 in which the interface
to realloc() is defined in a way that specifies [one way or
another] what happens to the input block when realloc() finds it
necessary to resort to the storage allocator ?
:Trying to figure out if realloc calls free or immediately deallocates or unmaps
:pages or anything else is breaking into the module without need. Even worrying
:about whether memory moves is irrelevant. Suppose realloc is able to remap a
:page so the phyical DRAM appears at a different address. Was memory moved or
:not? MU.

Perhaps my reference to free() confused the matter. For my purposes,
I do not care whether realloc() calls free() or timuktu() or
touch_your_toes () or just directly manipulates the storage pools:
my question is: in the case that realloc() returns a different
pointer than was input, then to avoid memory leaks, is it necessary
or forbidden to free() the memory at the previous pointer -- or is it
not specified ? The other posters have pointed to language in C99
that make it clear for C99, but I (the OP) and a number of other posters
have not been able to find any "promise" or interface specification
in C89 that says unambiguously what the behaviour is. (And that's
not even counting the sub-discussion about realloc() with size 0.)

My user and I would be happy to live with whatever the interface
specification -is-, but what *is* that specification?? Where is it
written in the C89 standard what exactly will happen?

--
"Never install telephone wiring during a lightning storm." -- Linksys

[Walter Roberson]

In article <11************ *@corp.supernew s.com>,
SM Ryan <wy*****@tang o-sierra-oscar-foxtrot-tango.fake.org> wrote:
:Read the quoted question, clemclone.
: does it free() the previously allocated block?
:That's a question about the implementation of realloc not the interface.

Is *that* what you've been going on about?

My Subject: line used "implicit free()". My final paragraph
used "free" without following (). My second-to-last paragraph
discussed that there was no documentation about how memory might
be deallocated by realloc() except by changing the size to 0.

It is true that I used "free()" in the line you quoted. Everyone
else appears to have interpreted the reference in context in
the generic "deallocati on" sense rather than as a literal call to free().

Let me then go back and rephrase my original question:

If I call realloc() with a non-NULL pointer to a block of
memory that was allocated with a non-zero size, and the new size
is also non-zero, and if realloc() returns a different pointer than
the original pointer, then in C89 may I free() the original
pointer without invoking unspecified or undefined behaviour?

[For this purpose, please note that C89 specifies that one
must not call free() upon a pointer to memory that has already
been deallocated.]
--
History is a pile of debris -- Laurie Anderson

[CBFalconer]

Walter Roberson wrote:

.... snip ...
Let me then go back and rephrase my original question:

If I call realloc() with a non-NULL pointer to a block of
memory that was allocated with a non-zero size, and the new size
is also non-zero, and if realloc() returns a different pointer
than the original pointer, then in C89 may I free() the original
pointer without invoking unspecified or undefined behaviour?

The answer is NO. A resounding NO. With the exception that if
realloc returns NULL the original pointer has not been freed, and
may now be. So change your query to read "returns a non-NULL
pointer different than the original ..."

--
Some useful references about C:
<http://www.ungerhu.com/jxh/clc.welcome.txt >
<http://www.eskimo.com/~scs/C-faq/top.html>
<http://benpfaff.org/writings/clc/off-topic.html>
<http://anubis.dkuug.dk/jtc1/sc22/wg14/www/docs/n869/> (C99)
<http://www.dinkumware. com/refxc.html> (C-library}
<http://gcc.gnu.org/onlinedocs/> (GNU docs)

[CBFalconer]

Walter Roberson wrote:

SM Ryan <wy*****@tang o-sierra-oscar-foxtrot-tango.fake.org> wrote:

:Some day you'll learn about modular programming. Most malloc libraries
:promise not to leak if you match allocates and free properly.

^
Please fix your unusual quote-char.

--
Some useful references about C:
<http://www.ungerhu.com/jxh/clc.welcome.txt >
<http://www.eskimo.com/~scs/C-faq/top.html>
<http://benpfaff.org/writings/clc/off-topic.html>
<http://anubis.dkuug.dk/jtc1/sc22/wg14/www/docs/n869/> (C99)
<http://www.dinkumware. com/refxc.html> (C-library}
<http://gcc.gnu.org/onlinedocs/> (GNU docs)

[SM Ryan]

ro******@ibd.nr c-cnrc.gc.ca (Walter Roberson) wrote:

# Could you point me to the portion of C89 in which the interface
# to realloc() is defined in a way that specifies [one way or
# another] what happens to the input block when realloc() finds it
# necessary to resort to the storage allocator ?

Of course it doesn't say what happens to the input block. That's the whole point.
The caller is free of concerns about the implementation of the function, only
the interface and its protocol.

# My user and I would be happy to live with whatever the interface
# specification -is-, but what *is* that specification?? Where is it
# written in the C89 standard what exactly will happen?

The specification is the input pointer value is generally no longer valid
and should not be used again in any calls or memory references;
you must instead use the output pointer value. And that in most malloc
libraries freed memory is eventually reused.

The the input pointer remains valid if the output pointer is null and the
length is greater than zero.

Whether the input and output pointers are the same is irrelevant, because
you should only be using the output pointer if the realloc was successful.

--
SM Ryan http://www.rawbw.com/~wyrmwif/
Title does not dictate behaviour.

[SM Ryan]

rl*@hoekstra-uitgeverij.nl (Richard Bos) wrote:
# SM Ryan <wy*****@tang o-sierra-oscar-foxtrot-tango.fake.org> wrote:
#
# > # > # ># If realloc() finds it necessary to move the memory block, then
# > # > # ># does it free() the previously allocated block?
# >
# > # Nope; that's probably why the OP wanted to know whether realloc() frees
# > # the block it is passed. If it didn't, and could leak, one could still
# > # implement a version which doesn't leak using malloc() and free(). From
# > # the answers to the OP one can conclude that this isn't necessary; but
# > # the question makes sense.
# >
# > Some day you'll learn about modular programming.
#
# And some day, you'll learn to post. Perhaps some day, much later, you'll
# even learn to read. Modular programming is not relevant to the OP's
# question.
#
# > Most malloc libraries promise
#
# What libraries promise is immaterial. The question was not about what
# they are likely to do, but about what they _must_ do.

What a sad person you are. So anxious to prove me wrong that you have to
argue against the whole idea of structured/modular/contract programming.

So sad.

--
SM Ryan http://www.rawbw.com/~wyrmwif/
She broke your heart and inadvertendentl y drove men to deviant lifestyles.

[ranjeet.gupta]

CBFalconer wrote:

tigervamp wrote:

Walter Roberson wrote:

If realloc() finds it necessary to move the memory block, then
does it free() the previously allocated block?
Yes.

The C89 standard has some reference to undefined behaviour if
one realloc()'s memory that was freed by realloc(), but the only
way explicitly mentioned in the C89 standard to free memory via
realloc() is to realloc() it down to 0 bytes.

Passing a pointer to realloc that points to memory free'd by _any_
function results in undefined behavior. If you successfully
realloc memory which results in the original object being
deallocated, you must provide a pointer to the new object created
by realloc in subsequent realloc calls as the old object has been
freed.

I had always assumed it would automatically free the previous
memory, but is the behaviour instead undefined [or defined as
not happening] ?

No, the behavior is well defined by the Standard, see section
7.20.3 of C99, I don't have a C89 copy handy.

No, I don't consider it well defined. It leaves too much up to the
implementation in the case of zero block size requests. This means
that NULL is not always a sign of failure, and that a non-NULL
return is not necessarily freeable or reallocable.

In my nmalloc implementation for DJGPP I have chosen to treat a
zero block size as a request for one byte, and let the alignment
mechanisms raise it as they will. This ensures that all successful
requests return a non-NULL pointer that can safely be used in
subsequent frees or reallocs. (It also has the convenient to me
side effect of ensuring space for some record-keeping in my code)

I suspect the standard is written to not invalidate the sloppier
malloc implementations already out there. In cases like this I
think it should include a recommended practice.

As I was going through the Recent replies on the realloc(),
I got some question and my annalysis on that, so regarding on these
please guide me where I fail on the theoritical and practical
Knowledge. I am not able to read all the thread in the replies as
due to some problem in the web server.

Point 1.

If we do the realloc then it means that we have allocated the
extended memory for the current memory, for which we have
reallocated it. Means I need not to free the previous memory
which I extendend to realloc if compiler allocates memory
(extended memory) from the place where intial memory was allocated.

And we need to free if the memory is allocated by the
(realloc)in the new region.

so the key is to always free the memory when you reallocate
the memory by realloc fucntion.

How much I am correct on the Point 1 ?

Point 2.

what is the diffrence between the calloc() and malloc()
As far As I know the basic diffrence is that
1. malloc takes 1 argumnets while calloc takes two
2. malloc initialise the memory with the garbage values while
calloc initialise it with 0 (Zero)
3. malloc allocates continious memeory i.e one Block while
calloc alloactes into the Block
calloc (100, 2) ,means two block of 100 memoty alloaction.

apart from the above is any more diffrence between them ??

Point 3.

This may be looks off topic to you but I have one thing to ask
is there any diffrence between the malloc and new ??

Point 4.

why we need to derefrence the pointers once we are are done with our
work; I am not aware of garbage collection, And where I can find the
memory leak into the program ?

Thanks In Advance
Regards
Ranjeet
--
"If you want to post a followup via groups.google.c om, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson

[Keith Thompson]

[ Obnoxious '#' quoting character fixed. ]
[ Excessively long lines re-wrapped. ]
SM Ryan <wy*****@tang o-sierra-oscar-foxtrot-tango.fake.org> writes:

ro******@ibd.nr c-cnrc.gc.ca (Walter Roberson) wrote:

Could you point me to the portion of C89 in which the interface
to realloc() is defined in a way that specifies [one way or
another] what happens to the input block when realloc() finds it
necessary to resort to the storage allocator ?

Of course it doesn't say what happens to the input block. That's the
whole point. The caller is free of concerns about the
implementation of the function, only the interface and its protocol.

My user and I would be happy to live with whatever the interface
specification -is-, but what *is* that specification?? Where is it
written in the C89 standard what exactly will happen?

The specification is the input pointer value is generally no longer valid
and should not be used again in any calls or memory references;
you must instead use the output pointer value. And that in most malloc
libraries freed memory is eventually reused.

The the input pointer remains valid if the output pointer is null and the
length is greater than zero.

Whether the input and output pointers are the same is irrelevant, because
you should only be using the output pointer if the realloc was successful.

I believe you're missing the point.

First, the original question was:

If realloc() finds it necessary to move the memory block, then
does it free() the previously allocated block?

I think the intent was to ask whether the previous block is
deallocated, not whether realloc() specifically calls the free()
function.

The prototype for realloc(), in both C90 and C99, is:

void *realloc(void *ptr, size_t size);

Here's the C90 specification of realloc() (7.10.3.4):

Description

The realloc function changes the size of the object pointed to by
ptr to the size specified by size. The contents of the object
shall be unchanged up to the lesser of the new and old sizes. If
the new size is larger, the value of the newly allocated portion
of the object is indeterminate. If ptr is a null pointer, the
realloc function behaves like the malloc function for the
specified size. Otherwise, if ptr does not match a pointer earlier
returned by the calloc, malloc, or realloc function, or if the
space has been deallocated by a call to the free or realloc
function, the behavior is undefined. If the space cannot be
allocated, the object pointed to by ptr is unchanged. If size is
zero and ptr is not a null pointer, the object it points to is
freed.

Returns

The realloc function returns either a null pointer or a pointer to
the possibly moved allocated space.

I find the statement that it "changes the size of the object"
confusing, and possibly wrong or meaningless. There's only an
indirect implication that realloc can deallocate space under some
circumstances, and nothing about what those circumstances are. We
know, based on common sense, that if realloc is asked to make an
object larger than its original size, and there isn't room to expand
it in place, it will allocate a new larger object, copy the old to the
new, deallocate the old, and return a pointer to the new -- but I see
nothing in the C90 definition that says the old object is deallocated.
Perhaps the authors of that section were so sure of the behavior that
they forgot to mention it.

Imagine a broken realloc() implementation that always allocates a new
object (copying as necessary) and returns a pointer to it, but never
deallocates the old object, either by calling free() or by some other
mechanism. A program using such an implementation would have a
serious memory leak.

I don't see how the C90 specification, quoted above, forbids such a
broken implementation.

A reasonable workaround, if you know that the implementation behaves
this way, would be to save the old pointer and explicitly call free()
on it after the realloc(). However, C90 does allow the old block to
be deallocated; if it does so, calling free() would invoke undefined
behavior.

All you can really do is cross your fingers and hope that the
realloc() implementation does deallocate the old block, even though
the standard doesn't explicitly require it to do so. As far as I
know, all real-world implementations do this; I'd be surprised to see
one that doesn't.

I think that's exactly why the wording was improved in C99 (7.20.3.4):

Description

The realloc function deallocates the old object pointed to by ptr
and returns a pointer to a new object that has the size specified
by size. The contents of the new object shall be the same as that
of the old object prior to deallocation, up to the lesser of the
new and old sizes. Any bytes in the new object beyond the size of
the old object have indeterminate values.

If ptr is a null pointer, the realloc function behaves like the
malloc function for the specified size. Otherwise, if ptr does not
match a pointer earlier returned by the calloc, malloc, or realloc
function, or if the space has been deallocated by a call to the
free or realloc function, the behavior is undefined. If memory for
the new object cannot be allocated, the old object is not
deallocated and its value is unchanged.

Returns

The realloc function returns a pointer to the new object (which
may have the same value as a pointer to the old object), or a
null pointer if the new object could not be allocated.

With this new specification, there is no potential memory leak, and
the broken implementation I described above is clearly forbidden. A
naive implementation could always allocate a new object and deallocate
the old one, but it's easy to optimize this by reusing the old object
in some cases. I don't believe the intent was to change or constrain
the behavior of realloc() relative to the C90 definition, merely to
describe it better.

So the original question was based on the flawed specification in the
C90 standard. Modular programming (which I'm sure most of us
understand perfectly well) implies that if you have a well defined
interface, you can depend on it without worrying about the internal
implementation. Nobody is disputing that. The issue here is that the
interface (C90's specification of realloc()) is not well defined.

I believe the intent is clear in both C90 and C99. A call to
realloc() that returns a pointer to a new block of memory can be
counted on to deallocate the old block *as if* by passing its address
to free(). Unfortunately, I can't prove that based on the C90
specification.

Finally, here's what the C99 Rationale has to say. (I hadn't checked
the Rationale when I wrote the above; it seems to confirm my
speculation.)

7.20.3.4 The realloc function

A null first argument is permissible. If the first argument is
not null, and the second argument is 0, then the call frees the
memory pointed to by the first argument, and a null argument may
be returned; C99 is consistent with the policy of not allowing
zero-sized objects.

A new feature of C99: the realloc function was changed to make
it clear that the pointed-to object is deallocated, a new object
is allocated, and the content of the new object is the same as
that of the old object up to the lesser of the two sizes. C89
attempted to specify that the new object was the same object as
the old object but might have a different address. This conflicts
with other parts of the Standard that assume that the address of
an object is constant during its lifetime. Also, implementations
that support an actual allocation when the size is zero do not
necessarily return a null pointer for this case. C89 appeared
to require a null return value, and the Committee felt that this
was too restrictive.

--
Keith Thompson (The_Other_Keit h) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.