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

[SM Ryan]

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

# That's not ALL you can do: you can also ask questions about paragraphs
# that one might have overlooked or which might have been clarified
# in addendums that one hasn't seen, which proscribe the behaviour
# of library routines so as to remove the ambiguity.

Do you have sample code of how to do that?

--
SM Ryan http://www.rawbw.com/~wyrmwif/
Why are we here?
whrp

[Russell Shaw]

Walter Roberson wrote:

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

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

That's not ALL you can do: you can also ask questions about paragraphs
that one might have overlooked or which might have been clarified
in addendums that one hasn't seen, which proscribe the behaviour
of library routines so as to remove the ambiguity.

If no-one happens to know the answer, or if the answer is
indeterminate, then one can sometimes write one's own routine that
avoids the indeterminate behaviour. In the case of realloc(),
since it is never -required- that the address be left unchanged,
one can write a replacement for realloc() in terms of malloc(),
a memory copy, and a free(), provided that one knows the current
size of the object at hand.

For the address to not change, the new realloc'd size must fit in
the same place. If there was occupied memory following your data
and you wanted to increase the size of your data, the realloc will
have to copy it all to a different location where it will fit.
In this case, the address *will* change.

[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: # That's not ALL you can do: you can also ask questions about paragraphs
# that one might have overlooked or which might have been clarified
# in addendums that one hasn't seen, which proscribe the behaviour
# of library routines so as to remove the ambiguity. Do you have sample code of how to do that?

Sure, but are you finding a deficiency in your existing facility to ask
intelligent questions about matters whose resolutions are not immediately
clear?
--
"[...] it's all part of one's right to be publicly stupid." -- Dave Smey

[S.Tobias]

S.Tobias <si***@famous.b edbug.pals.inva lid> wrote:

Eric Sosman <es*****@acm-dot-org.invalid> wrote:

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

Taken in isolation, this sentence says that struct s { char c[30000]; } x = { 0 };
struct s *p = malloc(1); /* assume success */
Just a thought:

There might actually be a reason to require `p' to have max alignment
(assignment-wise) for `malloc(0)'. It is even documented in
the Rationale:
OBJ *p = calloc(0, sizeof(OBJ));
The Standard obviously wants to support zero-length array paradigm,
although zero-size objects are not supported.

`malloc(1)' may be considered as "a zero-length array (of any type)
plus 1 byte ``padding'' ".
When you need a zero-length array, but at the same time you need
a unique pointer (and it is not known if malloc(0) returns NULL
or not), then malloc(1) (or generally: malloc(n*size+1 ), n==0,1,2,...)
will always provide such pointer.

Therefore we actually want `malloc(n)' to return for every `n' a value
that is aligned suitably for any type.
*p = x;

However I still can't see any reason to require max alignment
access-wise (more than the requested size), but maybe this is just
not to make things too complicated. The Standard could simply
say that the returned pointer value has maximum alignment, but
for strange reason it chose to say in a circuitous way that the
alignment is maximal both assignment-wise and access-wise (which
is exactly the same thing), forgetting that access itself is
not always possible.
[Sorry for being a little ironic last time.]

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

[Walter Roberson]

In article <lo************ @main.anatron.c om.au>,
Russell Shaw <rjshawN_o@s_pa m.netspace.net. au> wrote:

Walter Roberson wrote:

one can sometimes write one's own routine that
avoids the indeterminate behaviour. In the case of realloc(),
since it is never -required- that the address be left unchanged,
one can write a replacement for realloc() in terms of malloc(),
a memory copy, and a free(), provided that one knows the current
size of the object at hand.

For the address to not change, the new realloc'd size must fit in
the same place. If there was occupied memory following your data
and you wanted to increase the size of your data, the realloc will
have to copy it all to a different location where it will fit.
In this case, the address *will* change.

Yes? I must be missing your point? Or did you perchance overlook
my double negative? "never required [...] left unchanged" means
"the routine may change the address under any circumstances it
feels fit."

If one writes a replacement version of realloc() in terms of
malloc/copy/free (and an additional parameter that indicates
the object's -current- size), then what one loses is the
-possibility- that the data won't have to move (and thus
be copied) if extra space just happens to be available
immediately after to the current object. But that's an
efficiency optimization; and especially if one is working with
large data sets, the extra efficiency might be pretty meaningless
compared to the possibility that one is leaking large chunks
of memory if indeed realloc() does not free the original
memory chunk when it happens to move data.
My user was satisfied with the posted analysis that in C99 the
as-if free() is explicit, and that in C89 the as-if free() is the
most reasonable interpretation. My commentatary in this sub-thread
is only around the point of whether I should have been telling my user
"You shouldn't even be -thinking- about whether there might be a memory
leak or not: it is Not Allowed to ask questions even to yourself about
anything not explicitly made clear in the one paragraph of the standard
most directly dedicated to defining the routine."
--
Any sufficiently old bug becomes a feature.

[Russell Shaw]

Walter Roberson wrote:

In article <lo************ @main.anatron.c om.au>,
Russell Shaw <rjshawN_o@s_pa m.netspace.net. au> wrote:

Walter Roberson wrote:

one can sometimes write one's own routine that
avoids the indeterminate behaviour. In the case of realloc(),
since it is never -required- that the address be left unchanged,
one can write a replacement for realloc() in terms of malloc(),
a memory copy, and a free(), provided that one knows the current
size of the object at hand.

For the address to not change, the new realloc'd size must fit in
the same place. If there was occupied memory following your data
and you wanted to increase the size of your data, the realloc will
have to copy it all to a different location where it will fit.
In this case, the address *will* change.

Yes? I must be missing your point? Or did you perchance overlook
my double negative? "never required [...] left unchanged" means
"the routine may change the address under any circumstances it
feels fit."

I saw the context of:

...one can write a replacement for realloc() in terms of malloc(),
memory copy, and a free(), provided that one knows the current
size of the object at hand.

combined with the context of the preceding part as meaning that
you could make it so that the returned address was never changed.
If one writes a replacement version of realloc() in terms of
malloc/copy/free (and an additional parameter that indicates
the object's -current- size), then what one loses is the
-possibility- that the data won't have to move
In other words, it *will* move. But not so. If the new size passed in
is smaller than the current size, you could just return the same address.
(and thus
be copied) if extra space just happens to be available
immediately after to the current object. But that's an
efficiency optimization; and especially if one is working with
large data sets, the extra efficiency might be pretty meaningless
compared to the possibility that one is leaking large chunks
of memory if indeed realloc() does not free the original
memory chunk when it happens to move data.
I know what you mean, but your double negatives are a bit confusing;)
My user was satisfied with the posted analysis that in C99 the
as-if free() is explicit, and that in C89 the as-if free() is the
most reasonable interpretation. My commentatary in this sub-thread
is only around the point of whether I should have been telling my user
"You shouldn't even be -thinking- about whether there might be a memory
leak or not: it is Not Allowed to ask questions even to yourself about
anything not explicitly made clear in the one paragraph of the standard
most directly dedicated to defining the routine."

ok

[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:
#
# ># That's not ALL you can do: you can also ask questions about paragraphs
# ># that one might have overlooked or which might have been clarified
# ># in addendums that one hasn't seen, which proscribe the behaviour
# ># of library routines so as to remove the ambiguity.
#
# >Do you have sample code of how to do that?
#
# Sure, but are you finding a deficiency in your existing facility to ask
# intelligent questions about matters whose resolutions are not immediately
# clear?

Simple 'no' would've sufficed.

Someday you'll learn about modular programming.

--
SM Ryan http://www.rawbw.com/~wyrmwif/
You face forward, or you face the possibility of shock and damage.

[CBFalconer]

Eric Sosman wrote:

Robert Gamble wrote:

.... snip ...

7.20.3p1 sentence 2:

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

Taken in isolation, this sentence says that

struct s { char c[30000]; } x = { 0 };
struct s *p = malloc(1); /* assume success */
*p = x;

should work: The allocation has succeeded, the returned value
is therefore suitably aligned for any type (`struct s' in
particular), the value can be assigned to any type of pointer
(including `struct s*'), and can then be used to access an
object of that type. All the preconditions of the sentence
are met -- and yet, the access is obviously not permitted.

However, if you follow that with:

if (tmp = realloc(p, sizeof *p) {
p = tmp;
*p = x;
}

access is perfectly legitimate, and p may not necessarily have
changed. The alignment is now needed.

--
Some informative links:
news:news.annou nce.newusers
http://www.geocities.com/nnqweb/
http://www.catb.org/~esr/faqs/smart-questions.html
http://www.caliburn.nl/topposting.html
http://www.netmeister.org/news/learn2quote.html

[CBFalconer]

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

--
Some informative links:
news:news.annou nce.newusers
http://www.geocities.com/nnqweb/
http://www.catb.org/~esr/faqs/smart-questions.html
http://www.caliburn.nl/topposting.html
http://www.netmeister.org/news/learn2quote.html

[Walter Roberson]

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

Someday you'll learn about modular programming.
My Magic 8-Ball seems to be out of order this evening; I don't
see how modular programming has to do with the question of whether
or not "all" one can do is interpret documentation narrowly and
at face value.

It seems to me that, in the absence of knowledge of whether
the as-if free() was or was not done, use of realloc() would
be contrary to Dijkstra's principles of structured programming
that routines should be -provably- correct. Code that leaks memory
(except at program exit) would seldom be "probably correct".

Someday you'll learn about modular programming.

A long time ago, in a galaxy far far away...
--
The rule of thumb for speed is:

1. If it doesn't work then speed doesn't matter. -- Christian Bau