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

[tigervamp]

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.
--
"This was a Golden Age, a time of high adventure, rich living and
hard dying... but nobody thought so." -- Alfred Bester, TSMD

Rob Gamble

[Dave Vandervies]

In article <d6**********@c anopus.cc.umani toba.ca>,
Walter Roberson <ro******@ibd.n rc-cnrc.gc.ca> wrote:

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

[#2] 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. |

[#4] 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.

So the old one always gets (conceptually) freed, though in practice it's
Highly Unlikely that you'll get a non-moving call to realloc actually
freeing anything (this is an excellent example of the as-if rule).

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.
The C89 draft I have here describes the same behavior, but it's less
clear that if the memory block fgets moved the old memory is deallocated.

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

a call to realloc can do one of three things:
-fail to resize the memory block and return NULL without deallocating
the old one
-resize the block in-place and return the same pointer you gave it
-resize-and-move the block with behavior equivalent to doing malloc-
memcpy-free yourself (except that the old and new blocks are allowed
to overlap - I don't know if there's any reasonable way to implement
it that actually would overlap them) and return a pointer to the new
memory block

None of these involve leaving old memory blocks unfree()d.
dave

--
Dave Vandervies dj******@csclub .uwaterloo.ca

I believe you have misspelled "painfully stupid" at the end of this sentence.
--Peter Seebach in comp.lang.c

[Eric Sosman]

Walter Roberson wrote:

If realloc() finds it necessary to move the memory block, then
does it free() the previously allocated block?
Yes. (Well, it might not actually call free(), but
the outcome will be the same.) C99 7.20.3.4/2:

The realloc function deallocates the old object [...]
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.
C89's language isn't as explicit, but throughout section
4.3.2 it keeps mentioning realloc() as one of the ways memory
can be deallocated, and in 4.10.3.4 it describes realloc() as
returning a pointer to the "possibly moved" memory. I think
the only reasonable reading of "moved" involves deallocation
of the previously-occupied space.
I had always assumed it would automatically free the previous memory,
but is the behaviour instead undefined [or defined as not happening] ?

A proper realloc() call can't invoke undefined behavior.
Even if C89 could be construed as not requiring the old memory
to be released, the behavior wouldn't be undefined -- you can't
refer to that old memory or to any pointer to it without invoking
undefined behavior, but simply leaking it isn't U.B. At worst
it'd be a QoI issue, with any implementation that leaked the
memory exhibiting negative QoI ...

--
Er*********@sun .com

[Walter Roberson]

In article <d6**********@n ews1brm.Central .Sun.COM>,
Eric Sosman <er*********@su n.com> wrote:

Walter Roberson wrote:

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

Yes. C89's language isn't as explicit,

Thanks, everyone; and thanks for recognizing that C89 isn't precise
on the point.
--
'ignorandus (Latin): "deserving not to be known"'
-- Journal of Self-Referentialism

[SM Ryan]

ro******@ibd.nr c-cnrc.gc.ca (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.

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

I did a debugging realloc that left the original block alone so that it could
dump an allocation history. There could be all kinds of exotic things happenning
to the previous memory: that's why you shouldn't concern yourself with it.

--
SM Ryan http://www.rawbw.com/~wyrmwif/
Elvis was an artist. But that didn't stop him from joining the service
in time of war. That's why he is the king, and you're a shmuck.

[CBFalconer]

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.

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

[Walter Roberson]

In article <11************ *@corp.supernew s.com>,
SM Ryan <wy*****@tang o-sierra-oscar-foxtrot-tango.fake.org> wrote:

ro******@ibd.n rc-cnrc.gc.ca (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.
--
'ignorandus (Latin): "deserving not to be known"'
-- Journal of Self-Referentialism

[SM Ryan]

ro******@ibd.nr c-cnrc.gc.ca (Walter Roberson) wrote:
# In article <11************ *@corp.supernew s.com>,
# SM Ryan <wy*****@tang o-sierra-oscar-foxtrot-tango.fake.org> wrote:
# >ro******@ibd.n rc-cnrc.gc.ca (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.

--
SM Ryan http://www.rawbw.com/~wyrmwif/
God's a skeeball fanatic.

[Robert Gamble]

On Fri, 20 May 2005 17:54:45 +0000, 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.

I was referring specifically to the behavior of realloc deallocating the
original object which is well defined.
This means that NULL is not always a sign of failure, and that a non-NULL
return is not necessarily freeable or reallocable.

NULL is always a sign of failure when the size provided is non-zero, if
you want to provide a size of zero is is easy enough to handle the return

What evidence do you have that a non-NULL value returned by realloc, when
provided a size of zero, cannot safely be passed to free() or realloc()?

Rob Gamble