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

[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: # 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;

Could you be so kind as to indicate where in C89 that specification
is given?

I've been reading and re-reading 4.10.3 "Memory Management
Functions" and I cannot seem to find any wording to that effect.

I'm not referring to "common practices" or "what a good implementation
would do". Any interface promise not written down in a C standard
is subject to alteration in the next edition of the DS9000 compiler.

But more seriously, any interface promise not written down in
a C standard is subject to alteration in the next edition of gcc
(and subject to being changed back in the dot release after that,
and changed back again in a later dot release, until eventually
RS decides that it's important to keep the odd behaviour in order
to prevent someone from putting out a software patent on it...)
--
Any sufficiently old bug becomes a feature.

[Joe Wright]

ra***********@g mail.com wrote:

[ much snippage ]

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.
Yes. You only free() the last address returned by realloc().
And we need to free if the memory is allocated by the
(realloc)in the new region.
No. There are no regions in play here.
so the key is to always free the memory when you reallocate
the memory by realloc fucntion.
No. You only free() the last address returned by realloc().

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 Yes. 2. malloc initialise the memory with the garbage values while
calloc initialise it with 0 (Zero) malloc() does not initialize memory. 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. No. malloc() and calloc() both allocate contiguous memory. The two
arguments to calloc() have no particular signifigance. (100,2) allocates
200 bytes.
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 ??
Yes. malloc() is defined by C, new is not.
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 ?
Wrong term. In C we dereference a pointer to yield the value to which it
points. free() does not do that. Rather free() de-allocates memory
allocated by its *alloc() siblings.
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

--
Joe Wright mailto:jo****** **@comcast.net
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein ---

[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:
#
# ># 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;
#
# Could you be so kind as to indicate where in C89 that specification
# is given?

page 155 line 19-20
page 156 line 22-24
page 144 line 14-16
# I've been reading and re-reading 4.10.3 "Memory Management
# Functions" and I cannot seem to find any wording to that effect.

If you wanted a verbatim transcript of the copyrighted work, why not ask
for it. Or if you have a copy and can't understand it, why do you need
someone to repeat words you are apparently incapable of understanding?

Or are you simply interesting in creating an argument because
you're bored?

# I'm not referring to "common practices" or "what a good implementation
# would do". Any interface promise not written down in a C standard
# is subject to alteration in the next edition of the DS9000 compiler.

You've got bigger problems than what the DS9000 compiler is doing.

--
SM Ryan http://www.rawbw.com/~wyrmwif/
This is one wacky game show.

[Keith Thompson]

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

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:

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

Could you be so kind as to indicate where in C89 that specification
is given?

page 155 line 19-20
page 156 line 22-24
page 144 line 14-16

My copy of the C90 standard (ANSI/ISO 9899-1900) does not have line
numbers on each page. I own both a hard copy (the left-hand pages of
Schildt's annotated version) and a soft copy, in PDF format. I do not
have a copy of the actual 1989 ANSI standard; my understanding is that
they are essentially identical except for some introductory matter and
some changes in the section numbering. Apparently the page numbers
also changed. Page 155 of the C90 standard does contain the
description of the realloc function, but page 156 describes atexit,
exit, and getenv, and page 144 describes ungetc and fread.

It's more useful to provide section numbers rather than page numbers.
For example, C90 7.10.3.4 describes the realloc function; that's
probably 4.10.3.4 in the C89 ANSI standard. It's even more useful to
provide brief quotations (I believe that's covered under fair use, but
IANAL).

Earlier today, I posted a followup in this thread, message-id
<ln************ @nuthaus.mib.or g>, in which I directly quoted the
section of the C90 standard that describes realloc(). Perhaps you can
reply to that and point out what you think I'm missing. It's
available at
<http://groups-beta.google.com/group/comp.lang.c/msg/988166ae47c087c b>.

I've been reading and re-reading 4.10.3 "Memory Management
Functions" and I cannot seem to find any wording to that effect.

If you wanted a verbatim transcript of the copyrighted work, why not ask
for it. Or if you have a copy and can't understand it, why do you need
someone to repeat words you are apparently incapable of understanding?

Or are you simply interesting in creating an argument because
you're bored?

I have also read the corresponding section of the C90 standard, and I
cannot find any explicit wording about the circumstances in which
realloc deallocates memory. We all know that that's the intent, but I
can't find the wording that expresses that intent.

In my opinion, the description of realloc in the C89/C90 standard was
poorly worded, and did not actually state that the old block of memory
is deallocated if a new one is allocated. This flaw is corrected in
the C99 standard, and commented on in the C99 Rationale.

It's entirely possible that I've missed something in the C90 standard
that makes this point clear. If so, I invite you to point it out to
us. Please note that insults about my reading comprehension skills do
not constitute pointing it out.

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

[S.Tobias]

Keith Thompson <ks***@mib.or g> wrote:

My copy of the C90 standard (ANSI/ISO 9899-1900) does not have line
numbers on each page. I own both a hard copy (the left-hand pages of
Schildt's annotated version) and a soft copy, in PDF format.

Where did you get C90 in PDF format, and how much does it cost?

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

[Keith Thompson]

"S.Tobias" <si***@FamOuS.B edBuG.pAlS.INVA LID> writes:

Keith Thompson <ks***@mib.or g> wrote:

My copy of the C90 standard (ANSI/ISO 9899-1900) does not have line
numbers on each page. I own both a hard copy (the left-hand pages of
Schildt's annotated version) and a soft copy, in PDF format.

Where did you get C90 in PDF format, and how much does it cost?

I bought it from ANSI for $18. I don't know whether it's still
available.

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

[S.Tobias]

Keith Thompson <ks***@mib.or g> wrote:

"S.Tobias" <si***@FamOuS.B edBuG.pAlS.INVA LID> writes:

Keith Thompson <ks***@mib.or g> wrote: Where did you get C90 in PDF format, and how much does it cost?

I bought it from ANSI for $18. I don't know whether it's still
available.

They sell only C99 now.

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

[Igmar Palsenberg]

CBFalconer wrote:
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.
The keyword is 'implementation defined'. It's up to the code to decide
what to do with a malloc(0) request : return NULL, return a unusable
pointer, or return a pointer with a certain usable space (1 byte is
commonly used).

Since 0 bytes isn't usable at all, you can simply assume that malloc(0)
doens't result in anything usable. My malloc() wrapper simply asserts on
a 0 byte request.
Is freeing NULL so generated accessing an object? Is freeing
non-NULL so generated accessing an object? When things are buried
in layers of code we can easily guarantee that the pointer was
created by malloc/realloc, and we can even guard it by making it
NULL after passing to free, but that guard won't work if realloc
can return a non-freeable pointer.

It doesn't say non-freeable : It says 'not be used to access an object'.
In other words : You can't use the allocated space.


Igmar

[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:
# 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: # ># 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; # Could you be so kind as to indicate where in C89 that specification
# is given? page 155 line 19-20
19 zero, the behaviour is implementation-defined; the value returned
shall be either a null pointer or a
20 unique pointer. The value of a pointer that refers to freed space
is indeterminate.
page 156 line 22-24
22 the callc, malloc, or reallc function, or if the space has been
deallocated by a call to
23 the free or realloc function, the behavior is undefined. If the
space cannot be allocated, the
24 object pointed to by ptr is unchanged. If size is zero and ptr
is not a null pointer, the object

page 144 line 14-16
14 int putc(int c, FILE *stream) ;

15 Description

16 The putc function is equivalent to fputc, except that if it
is implemented as a macro, it

# I've been reading and re-reading 4.10.3 "Memory Management
# Functions" and I cannot seem to find any wording to that effect. If you wanted a verbatim transcript of the copyrighted work, why not ask
for it.
I have the hard copy. I can't find any date when the copy itself was
printed, but it is old enough to literally be falling apart with use,
especially at page 154/155.
Or if you have a copy and can't understand it, why do you need
someone to repeat words you are apparently incapable of understanding?
Well, the C89 standard is a large document, and sometimes important
points in it are not in the obvious places, so I was hoping you had
found a section that I had missed. The sections you indicated above
unfortunately do not establish the validity of the claims you have
made.

If you re-examine page 156 lines 17 through 25, you will find
that deallocation is mentioned in two contexts:

a) that if the space pointed to has already been deallocated by
free() or realloc(), the behaviour is undefined;

b) that if the size is 0 and the pointer is non-null, the object
is freed.

Thus, the *only* instance in section 4.10.3.4 (page 156) in which
realloc() promises to free memory is if the size is 0 (and the
pointer non-null). There is no interface promise in *that* section
that the old object will be freed when the data is moved.
And there isn't any such interface promise about realloc() in
section 4.10.3 "Memory Management Functions" (page 155) either.

Thus, the wording in 4.10.3.4 about indeterminate behaviour
when "space has been deallocated by a call to the free() or
realloc() function" [pg 156 lines 22-23] is only certain to apply
if when realloc()'d with a size of 0. Otherwise, if one changed
sizes and realloc() happened to move the memory, then the
old pointer *does* "match a pointer earlier returned by
the calloc(), malloc(), or realloc() function" [pg 156 lines 21-22],
and in that instance, the C89 standard does not express any
indeterminacy of the operation.

Or are you simply interesting in creating an argument because
you're bored?
Not at all. You seem very certain that certain "modular
programming" interface promises have been made in the C89
definition of realloc(), but when I [or anyone else I've shown
the section to] examine the standards, we don't seem to find those
interface promises anywhere. Many would assume that you are wrong,
but I assume that you have a good reason for saying what
you are saying, and I ask for clarification.

You've got bigger problems than what the DS9000 compiler is doing.

Sure do. I'm in the middle of trying to convince my management to
spend a raft of money on network improvements. Interpreting the C89
standard is simple compared to convincing scientists to contribute
a share of their grants to a common cause.
--
Look out, there are llamas!

[Dave Vandervies]

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

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 ?
Everybody else seems to understand that; there's no need to waste your
time and energy arguing it with this guy. (Unless, of course, you enjoy
doing so. Everybody who's not actively participating has either made
popcorn or killfiled the thread by now.)

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
specificatio n -is-, but what *is* that specification?? Where is it
written in the C89 standard what exactly will happen?

The draft I have describes realloc's behavior as "changes the size of the
object pointed to by ptr" (4.10.3.4; I believe this is the ANSI numbering
but I'm not certain - it's the draft that came from Dan Pop's collection).
If it's changing the size and not creating a new one, there's no old
one left behind for you to free.

So it seems to me that the specification is there, it's just not as
clear as in C99.
dave

--
Dave Vandervies dj******@csclub .uwaterloo.ca
Hmmm, I know some folks are not at all disturbed by getting flamed,
but it's not often I see someone actively try to jump into a fire.
--Mike Wahler in comp.lang.c