realloc() implicit free() ?

[S.Tobias]

No. malloc has no way of knowing what such a requirement is.

Of course not. It would have to return maximum object size.
There would have to be maximum object size.

 

[Richard Bos]

As I read the following from N869:

7.20.3 Memory management functions

[#1] The order and contiguity of storage allocated by
successive calls to the calloc, malloc, and realloc
functions is unspecified. The pointer returned if the
allocation succeeds is suitably aligned so that it may be
assigned to a pointer to any type of object and then used to
access such an object or an array of such objects in the
space allocated (until the space is explicitly freed or
reallocated). Each such allocation shall yield a pointer to
an object disjoint from any other object. The pointer
returned points to the start (lowest byte address) of the
allocated space. If the space cannot be allocated, a null
pointer is returned. If the size of the space requested is
zero, the behavior is implementation-defined: either a null

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
pointer is returned, or the behavior is as if the size were
some nonzero value, except that the returned pointer shall
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
not be used to access an object. The value of a pointer
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
that refers to freed space is indeterminate.

Is freeing NULL so generated accessing an object? Is freeing
non-NULL so generated accessing an object?

I should hope not. If it is, then

int *x;
x=malloc(100);
free(x);

invokes undefined behaviour. When the memory is received from malloc(),
it contains uninitialised bytes; it never is given a real value;
therefore, accessing it is accessing an uninitialised int value, which
invokes UB (may be a trap representation). Therefore, if free() accessed
the object its argument points at, that code would possibly access a
trap representation. But TTBOMK, it's valid code. Because of this, I
conclude that so is

int *x;
x=malloc(0);
free(x);

since free() doesn't access *x in this case, either.

Richard

 

[Richard Bos]

[ Learn to quote, damn it. ]

(e-mail address removed)-cnrc.gc.ca (Walter Roberson) wrote:
# In article <[email protected]>,
# >[email protected] (Walter Roberson) wrote:
# ># If realloc() finds it necessary to move the memory block, then
# ># does it free() the previously allocated block?
#
# >You're over-specifying the function. What happens to the block is irrelevant
# >to understanding the function. Use the address returned by realloc; don't
# >worry about what it was before.
#
# The question is not over-specified if one is concerned about
# whether one is leaking memory. When your datasets are ~1 Gb each
# and you are handling them in a loop, you can't afford to allow memory
# to leak.

All you can do to prevent leaks is to match frees to allocs; you don't need to
know how the library is implemented to do that much. It's still leaking
you're stuck unless you can get the library source code.

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.

Richard

 

[Chris Croughton]

In other words, if we have a system on which we can detect "failure
to align for any object whatsoever" by just using ordinary pointer
assignments, *then* that system will have to do 16-byte (or whatever)
alignment for a 3-byte malloc; but if the system handles "misaligned"
pointers without trouble, as long as they are not used to access
their misaligned objects, then -- because there will be no way for
the user to tell -- the as-if rule will allow us to implement
malloc(3) with just two-byte alignment.

Is there anything which says that alignments are always on a power of 2?
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).

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).

Chris C

 

[SM Ryan]

# > # ># 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. Most malloc libraries promise
not to leak if you match allocates and free properly. So with modular programming
you concentrate on the interface (matching allocates and frees) and not worry
about how the other modules fulfills its promises.

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).

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.

 

[tigervamp]

# > # ># 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. Most malloc libraries promise
not to leak if you match allocates and free properly. So with modular programming
you concentrate on the interface (matching allocates and frees) and not worry
about how the other modules fulfills its promises.

You have completely missed the point numerious times in this thread
with your remarks so let me spell it out for you: The OP was asking
about the "promises" of the "interface" provided by the Standard. It
was a completely valid question, you cannot properly use the function
in question without knowing the answer. Either realloc frees memory or
it doesn't. If it doesn't then you must free it yourself in specific
scenerios or introduce a memory leak. If is does, then attempting to
free the memory yourself would lead to undefined behavior. Try to
understand this before you post again.

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).

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.

Rob Gamble

 

[SM Ryan]

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

# You have completely missed the point numerious times in this thread
# with your remarks so let me spell it out for you: The OP was asking
# about the "promises" of the "interface" provided by the Standard. It

Read the quoted question, clemclone.
does it free() the previously allocated block?
That's a question about the implementation of realloc not the interface.
In modular programming you don't worry about what realloc does. You only
worry about the interface. The interface has two important points on
realloc:

If you match allocates and frees, most mallocs promise not
to leak.

Use the output pointer of realloc and no longer the input.

Follow these a few other interface rules and and you don't have to
worry whether realloc calls free() or sbrk() or mapin() or anything
else.

# was a completely valid question, you cannot properly use the function
# in question without knowing the answer. Either realloc frees memory or
# it doesn't. If it doesn't then you must free it yourself in specific

You're not programming modularly if you need to know how realloc works.
For me it is sufficient to know that if I match frees with allocates
and use the current block pointers, the library promises to reuse memory
eventually. How and when are irrelevant to me.

# scenerios or introduce a memory leak. If is does, then attempting to
# free the memory yourself would lead to undefined behavior. Try to
# understand this before you post again.

Knowing the interface does not require knowing whether realloc calls
free(). I really don't care if realloc calls free. What I care about
is when I call free(), everything back to the original malloc or
realloc will be recycled.

 

[S.Tobias]

I should hope not. If it is, then

int *x;
x=malloc(100);
free(x);

invokes undefined behaviour. When the memory is received from malloc(),
it contains uninitialised bytes; it never is given a real value;
therefore, accessing it is accessing an uninitialised int value, which
invokes UB

But free could write the object, which also counts as an access.

But anyway, I think that everybody now agrees that free() does not
access anything.

 

[Richard Tobin]

The only thing being discussed here is alignmentment requirements. The
above quote states that your object created with malloc will be properly
*aligned* to hold any type, not that any type can actually be stored in it
if the space doesn't exist.

But no conforming program can tell the difference, so the statement
places no constraint on implementations.

-- Richard

 

[Eric Sosman]

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.

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.

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."

 

[Chris Croughton]

Not to my knowledge.


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...

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]

# > # ># 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]

: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
ages 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
age 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?

 

[Walter Roberson]

: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 "deallocation" 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.]

 

[CBFalconer]

.... 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]

:Some day you'll learn about modular programming. Most malloc libraries
romise 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]

(e-mail address removed) (Richard Bos) 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]

(e-mail address removed)-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.

 

[ranjeet.gupta]

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

 

[Keith Thompson]

[ Obnoxious '#' quoting character fixed. ]
[ Excessively long lines re-wrapped. ]

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.