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

[S.Tobias]

CBFalconer <cb********@yah oo.com> wrote:

"S.Tobias" wrote:

... snip ...

How about this: I say the Standard requires `malloc(1)' to return
at least enough space to accommodate `struct s'.
Stretched? Yes, but fits your assumptions better.

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.

--
Stan Tobias
mailx `echo si***@FamOuS.Be dBuG.pAlS.INVALID | sed s/[[:upper:]]//g`

[Richard Bos]

CBFalconer <cb********@yah oo.com> wrote:

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]

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

[ Learn to quote, damn it. ]

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.

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]

On 21 May 2005 16:40:23 GMT, Chris Torek
<no****@torek.n et> wrote:

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.

--
SM Ryan http://www.rawbw.com/~wyrmwif/
The little stoner's got a point.

[tigervamp]

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

--
SM Ryan http://www.rawbw.com/~wyrmwif/
The little stoner's got a point.

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.

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

[S.Tobias]

Richard Bos <rl*@hoekstra-uitgeverij.nl> wrote:

CBFalconer <cb********@yah oo.com> wrote:

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

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.

--
Stan Tobias
mailx `echo si***@FamOuS.Be dBuG.pAlS.INVALID | sed s/[[:upper:]]//g`

[Richard Tobin]

In article <pa************ *************** *@gmail.com>,
Robert Gamble <rg*******@gmai l.com> wrote:

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]

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

--
Eric Sosman
es*****@acm-dot-org.invalid