realloc() implicit free() ?

W

Walter Roberson

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

Joe Wright

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

SM Ryan

(e-mail address removed)-cnrc.gc.ca (Walter Roberson) wrote:
# In article <[email protected]>,
# >[email protected] (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.
 
K

Keith Thompson

[ Obnoxious '#' quoting character fixed. ]
SM Ryan said:
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
<[email protected]>, 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
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.
 
S

S.Tobias

Keith Thompson said:
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?
 
K

Keith Thompson

S.Tobias said:
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.
 
I

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
 
W

Walter Roberson

(e-mail address removed)-cnrc.gc.ca (Walter Roberson) wrote:
# In article <[email protected]>,
# >[email protected] (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.
 
D

Dave Vandervies

Walter Roberson said:
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
specification -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
 
C

CBFalconer

Dave said:
.... snip ...

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.

Does anyone know what happened to Dan? Just before he disappeared
he seemed to be looking for a new position, and then he showed up
momentarily from Switzerland. He added a great deal here,
including insults :) He and Richard Heathfield are welcome to
return.

--
Some informative links:
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
 
P

Paul Mesken

Why couldn't somebody write him an email and ask how he is doing?

Google says he's over at comp.std.c

Relax! His last post was on May the 16th (or perhaps he's busy posting
on c.l.c.moderated but we won't be able to see his posts for the next
two months ;-)

I'm much more interested in where my treacherous sidekick Stephan
Wilms is :)
 
T

Tim Rentsch

Chris Croughton said:
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).

Here's a reason you might not have thought of why it's important
to always align for all possible element types.

Suppose we have a union type

union variant_union_tag {

struct {
uint8_t kind;
} variant_indicator_byte;

struct {
uint8_t kind;
char c[1024*1024];
} char_variant;

struct {
uint8_t kind;
short s[1024*1024];
} short_variant;

struct {
uint8_t kind;
int i[1024*1024];
} int_variant;

struct {
uint8_t kind;
long l[1024*1024];
} long_variant;

struct {
uint8_t kind;
long_long ll[1024*1024];
} long_long_variant;

};

...

union variant_union_tag *v = malloc( sizeof v->variant_indicator_byte );
if( ! v ) bail( "no memory" );
v->variant_indicator_byte.kind = 0;

...

union variant_union_tag new_v;
switch( some_value ){
case 0: break;
case 1: new_v = realloc( v, sizeof v->char_variant ); break;
case 2: new_v = realloc( v, sizeof v->short_variant ); break;
case 3: new_v = realloc( v, sizeof v->int_variant ); break;
case 4: new_v = realloc( v, sizeof v->long_variant ); break;
case 5: new_v = realloc( v, sizeof v->long_long_variant ); break;

default: bail( "some_value has bogus value" );
}
if( ! new_v ) bail( "realloc failed" );
v = new_v;
v->variant_indicator_byte.kind = some_value;

It's possible the realloc will succeed without moving the underlying
object. Thus, it must have been properly aligned at the very
beginning.

Of course, it's possible to imagine complicated strategies that note
sizes and possible alignments and force movement in cases where lack
of proper alignment may cause problems. At a systems level, though,
it's almost certainly better to have a simpler allocation algorithm
that just uses the least common multiple of all alignment
requirements. If you want something finer grained, use 'malloc()' to
get a big chunk and sub-allocate out of it. For 99+% of applications,
however, using malloc is good enough.

I have to admit that I got a good laugh when I saw that on a certain
proprietary OS (sold by a Redmond-based company) the storage overhead
for 'malloc()' is more than 50 bytes (on an x86 processor). I expect
though that most implementations are more reasonable.
 
C

CBFalconer

Tim said:
.... snip ...

I have to admit that I got a good laugh when I saw that on a
certain proprietary OS (sold by a Redmond-based company) the
storage overhead for 'malloc()' is more than 50 bytes (on an
x86 processor). I expect though that most implementations are
more reasonable.

It is quite conceivable. My nmalloc, for 32 bit operation under
DJGPP, uses 16 bytes, with an option for 24 (and more protection).
For a 64 bit system using 48 bytes is quite reasonable. My usage
is:

size
up pointer
down pointer (these two link to adjacent space)
free identifier and link (null when allocated)
free space link (these two manipulate the free space)
guard
allocated space
guard

The guards allow detection of overruns. Eliminating them and
putting the second free space link in the actual free space cuts it
down to 16 bytes. All this allows all operations to be O(1). If
you add some features (such as garbage collection, usage counts,
etc) you can easily push it up. Details of my version are at:

<http://cbfalconer.home.att.net/download/nmalloc.zip>
 
R

ranjeet.gupta

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

I got bit confused by your commnets so let me berif myself what
I said.

Suppose we have the memory of 10 bytes,
2000 to 2010;

Case 1:

now if i allocate the memory with the malloc like
malloc(6), Then let say that the memroy will be allocated
from 2000 to 2005,

Now I realloc it let say,
realloc(8), Then the memory will be allocated
from the 2000 to 2007,

Now for the above case we do not need to free the memory ...right.

Case 2:

Now take the other case,
we have to realloc with 20
realloc(20); Overe here The memory is not available

so the whole chunk of memory will be allocated in the new
available place. ... right.

let say it is allocated from 5000 to 5019,
now in this case we have to free the 2000 to 2005 memory loaction.

realloc returns the address of the location where the memory
has been alloctaed , in the above case will return 5000

what do you mean by the last address return ?? This is confusing
me. Please clarify.
malloc() does not initialize memory.

correct i was wrong while using the words in my statement.
No. malloc() and calloc() both allocate contiguous memory. The two
arguments to calloc() have no particular signifigance. (100,2) allocates
200 bytes.

So what is the Diffrence then why specifically you need the
two arguments for this calloc() ? The block allocation
makes more sense for the two arguments passed to the
calloc (May Be I May Be Wrong Do Correct Me)
 
R

ranjeet.gupta

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

I got bit confused by your commnets so let me berif myself what
I said.

Suppose we have the memory of 10 bytes,
2000 to 2010;

Case 1:

now if i allocate the memory with the malloc like
malloc(6), Then let say that the memroy will be allocated
from 2000 to 2005,

Now I realloc it let say,
realloc(8), Then the memory will be allocated
from the 2000 to 2007,

Now for the above case we do not need to free the memory ...right.

Case 2:

Now take the other case,
we have to realloc with 20
realloc(20); Overe here The memory is not available

so the whole chunk of memory will be allocated in the new
available place. ... right.

let say it is allocated from 5000 to 5019,
now in this case we have to free the 2000 to 2005 memory loaction.

realloc returns the address of the location where the memory
has been alloctaed , in the above case will return 5000

what do you mean by the last address return ?? This is confusing
me. Please clarify.
malloc() does not initialize memory.

correct i was wrong while using the words in my statement.
No. malloc() and calloc() both allocate contiguous memory. The two
arguments to calloc() have no particular signifigance. (100,2) allocates
200 bytes.

So what is the Diffrence then why specifically you need the
two arguments for this calloc() ? The block allocation
makes more sense for the two arguments passed to the
calloc (May Be I May Be Wrong Do Correct Me)
 
K

Keith Thompson

It's easier to follow the discussion if you left-justify your text.
Indented text tends to look like it's a quotation.

I got bit confused by your commnets so let me berif myself what
I said.

Suppose we have the memory of 10 bytes,
2000 to 2010;

I think you mean 2000 to 2009.
Case 1:

now if i allocate the memory with the malloc like
malloc(6), Then let say that the memroy will be allocated
from 2000 to 2005,

Now I realloc it let say,
realloc(8), Then the memory will be allocated
from the 2000 to 2007,

Now for the above case we do not need to free the memory ...right.

Case 2:

Now take the other case,
we have to realloc with 20
realloc(20); Overe here The memory is not available

so the whole chunk of memory will be allocated in the new
available place. ... right.

let say it is allocated from 5000 to 5019,
now in this case we have to free the 2000 to 2005 memory loaction.

No. This is really simpler than you're making it out to be.

A successful call to malloc() or calloc() allocates a contiguous block
of memory and returns a pointer to it. (An unsuccessful call returns
NULL.) This memory eventually needs to be deallocated.

A successful call to realloc() allocates a contiguous block of memory,
copies the contents of the old block to the new block, deallocates the
old block, and returns a pointer to the new block. (An unsuccessful
calls returns NULL and leaves the old block alone.) This is true
regardless of whether the new size is less than, equal to, or greater
than the old size. Since the old block of memory has been
deallocated, the old pointer is indeterminate; you shouldn't try to do
anything with it.

Another way of looking at this is that realloc() effectively changes
the size (and possibly the location) of an allocated object. That
interpretation has some problems, though, because it's not really the
same object; it's a new object with the contents of the old object.

As it happens, an implementation will often (but not always) be able
to optimize the allocate/copy/deallocate sequence by re-using the old
object. The circumstances in which it can do this are
implementation-specific, and you shouldn't depend on any particular
behavior. Even if the new size is the same as the old size, the
implementation might use the realloc() as an opportunity to
consolidate free space.

Here's an example. Please note that the following is simplified code,
not to be used in real life. I'm ignoring the possibility that
malloc() or realloc() could fail.

char *ptr;
ptr = malloc(1000);
/*
* We have a 1000-byte buffer.
* After a while, we need more space.
*/
ptr = realloc(ptr, 2000);
/*
* Now we have a 2000-byte buffer.
* After a while, we don't need the whole thing.
*/
ptr = realloc(ptr, 500);
/*
* Now we have a 500-byte buffer.
* Eventaully, we're finished with it.
*/
free(ptr);

As this code executes ptr could point to three different locations in
memory, or it could point to the same location each time. We don't
know, and we don't care. Each call to realloc() deallocates the old
buffer and allocates a new one (possibly in the same place). We only
need to call free() when we're done with the last allocated buffer;
the others were all deallocated by realloc().

Why is this simplified code bad? First, I didn't check whether the
initial malloc() return NULL, indicating an allocation failure; if it
does, any attempt to use the allocated block can cause bad things
to happen. Second, if the realloc() call in
ptr = realloc(ptr, 2000);
fails, realloc() returns NULL, but the previously allocated block is
left alone. By assigning the result of realloc() to ptr, I may have
destroyed my only pointer to the allocated block, creating a memory
leak. If you want to be able to recover from a realloc() failure, you
need to assign the result to a separate pointer variable which you
then check for NULL.

[...]

Joe said:
So what is the Diffrence then why specifically you need the
two arguments for this calloc() ? The block allocation
makes more sense for the two arguments passed to the
calloc (May Be I May Be Wrong Do Correct Me)

It's probably just for historical reasons. calloc() is typically used
to allocate space for an array; it's convenient to pass the element
size and the number of elements as separate arguments.
 
J

Joe Wright

Joe said:
(e-mail address removed) wrote:

[ much snippage ]


No. You only free() the last address returned by realloc().


I got bit confused by your commnets so let me berif myself what
I said.

Suppose we have the memory of 10 bytes,
2000 to 2010;

That would be eleven bytes.
Case 1:

now if i allocate the memory with the malloc like
malloc(6), Then let say that the memroy will be allocated
from 2000 to 2005,

Now I realloc it let say,
realloc(8), Then the memory will be allocated
from the 2000 to 2007,

Now for the above case we do not need to free the memory ...right.
Right.

Case 2:

Now take the other case,
we have to realloc with 20
realloc(20); Overe here The memory is not available

so the whole chunk of memory will be allocated in the new
available place. ... right.

let say it is allocated from 5000 to 5019,
now in this case we have to free the 2000 to 2005 memory loaction.
No. The realloc() function will do that for you.
realloc returns the address of the location where the memory
has been alloctaed , in the above case will return 5000

what do you mean by the last address return ?? This is confusing
me. Please clarify.

Use malloc() to allocate a region of memory of a certain size.

char *recon, *trial;
recon = malloc(20 * sizeof *recon);
if (!recon) bail(); /* Whatever you like when memory is exhausted */

Now you determine that the memory at recon needs to be increased.

trial = realloc(recon, 100 * sizeof *trial);

If realloc fails, trial is NULL and recon is still valid. If trial is
not NULL then realloc succeeded and trial is the new memory and recon
has been freed.

if (trial) recon = trial; /* if realloc succeeds */

Please read your C book and write more little programs.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
474,164
Messages
2,570,898
Members
47,440
Latest member
YoungBorel

Latest Threads

Top