By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
454,121 Members | 1,008 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 454,121 IT Pros & Developers. It's quick & easy.

realloc return value

P: n/a
I have taken the following prototype from K & R.

void *realloc(void *p, size_t size);

Suppose p was earlier allocated by malloc. Suppose I am calling realloc
with larger size value.
If realloc is successful, will the return pointer be the same as p or
will it be different.
K & R 2nd edition says "realloc returns a pointer to the new space".

Why I am asking is that if they are different, the older pointer value
of p should be freed.

Thanks

Dec 20 '06 #1
Share this Question
Share on Google+
12 Replies


P: n/a
subramanian a écrit :
I have taken the following prototype from K & R.

void *realloc(void *p, size_t size);

Suppose p was earlier allocated by malloc. Suppose I am calling realloc
with larger size value.
If realloc is successful, will the return pointer be the same as p or
will it be different.
K & R 2nd edition says "realloc returns a pointer to the new space".

Why I am asking is that if they are different, the older pointer value
of p should be freed.

Thanks
You do not have to free the old value. realloc will do it for you
Dec 20 '06 #2

P: n/a
subramanian said:
I have taken the following prototype from K & R.

void *realloc(void *p, size_t size);

Suppose p was earlier allocated by malloc. Suppose I am calling realloc
with larger size value.
If realloc is successful, will the return pointer be the same as p or
will it be different.
It *may* be different. That depends on whether realloc relocated the block
(and also on whether realloc succeeded). If it did relocate the block, p's
value is now indeterminate and should not be used. And if it failed,
realloc will return NULL. See below.
K & R 2nd edition says "realloc returns a pointer to the new space".

Why I am asking is that if they are different, the older pointer value
of p should be freed.
No, realloc will take care of that for you if it is necessary.

Note that realloc may *fail*, in which case it will return NULL. So don't do
this:

p = realloc(p, new_size); /* BAD DOG! NO BISCUIT! */

Instead, do this:

tmp = realloc(p, new_size);
if(tmp != NULL)
{
p = tmp;
tmp = NULL;
}
else
{
the reallocation failed, but at least p still points to the
old, untouched memory block, so you haven't *lost* any memory
}

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.
Dec 20 '06 #3

P: n/a

subramanian wrote:
I have taken the following prototype from K & R.

void *realloc(void *p, size_t size);

Suppose p was earlier allocated by malloc. Suppose I am calling realloc
with larger size value.
If realloc is successful, will the return pointer be the same as p or
will it be different.
We don't know, and we don't need to care. If it's not null, the
reallocation worked (and that could conceivably be by growing the
allocated memory in place, AFAIK), the old data has been (if necessary)
copied into the new location. If the old base address and the new base
address are different, the previously allocated space will have been
freed.
K & R 2nd edition says "realloc returns a pointer to the new space".
Why I am asking is that if they are different, the older pointer value
of p should be freed.
But not by you. That's realloc()'s job.

Dec 20 '06 #4

P: n/a

subramanian wrote:
I have taken the following prototype from K & R.

void *realloc(void *p, size_t size);

Suppose p was earlier allocated by malloc. Suppose I am calling realloc
with larger size value.
If realloc is successful, will the return pointer be the same as p or
will it be different.
I've just checked with a copy of the draft C89 standard and it says
that the return pointer could be either...

Dec 20 '06 #5

P: n/a
>Da: jacob navia
>Data: Mer 20 Dic 2006 13:20
....
>Da: Richard Heathfield
Data: Mer 20 Dic 2006 13:29
...
really strange:
jacob posted his message a couple of hours ago, and richard hadn't
"attaked" (harrassed ?) him ...
really strange
ah: got it ! they're disputating in the good ol' "size of pointers"
thread !
i would say: "they're not multithreaded" ... but the standard doesn't
know about threads
;-)

Dec 20 '06 #6

P: n/a
indro said:
>>Da: jacob navia
Data: Mer 20 Dic 2006 13:20
...
>>Da: Richard Heathfield
Data: Mer 20 Dic 2006 13:29
..
really strange:
jacob posted his message a couple of hours ago, and richard hadn't
"attaked" (harrassed ?) him ...
If he didn't screw up, why should I reply? What do you want me to say -
"Well done Mr Navia, you finally got something right"? Would not that, too,
be construed as an "attack" by those who think (wrongly) that I've got it
in for him?

And if he did screw up and I didn't reply, well, so what? I'm under no
obligation to correct /all/ the screw-ups posted here.
really strange
ah: got it ! they're disputating in the good ol' "size of pointers"
thread !
What dispute? The Standard is clear on the matter.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.
Dec 20 '06 #7

P: n/a
In article <11**********************@a3g2000cwd.googlegroups. com>,
<ma**********@pobox.comwrote:
>Suppose p was earlier allocated by malloc. Suppose I am calling realloc
with larger size value.
If realloc is successful, will the return pointer be the same as p or
will it be different.
>We don't know, and we don't need to care.
Of course we have to care: we have to change any variables that
pointed to the old data so they point to the new data. In effect,
you have to assume that it *is* different.

-- Richard
--
"Consideration shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963.
Dec 20 '06 #8

P: n/a

Richard Tobin wrote:
In article <11**********************@a3g2000cwd.googlegroups. com>,
<ma**********@pobox.comwrote:
Suppose p was earlier allocated by malloc. Suppose I am calling realloc
with larger size value.
If realloc is successful, will the return pointer be the same as p or
will it be different.
We don't know, and we don't need to care.

Of course we have to care: we have to change any variables that
pointed to the old data so they point to the new data. In effect,
you have to assume that it *is* different.
Fair comment. (This group helps me learn...)

Dec 20 '06 #9

P: n/a
ma**********@pobox.com wrote:
>
subramanian wrote:
I have taken the following prototype from K & R.

void *realloc(void *p, size_t size);

Suppose p was earlier allocated by malloc. Suppose I am calling
realloc with larger size value.
If realloc is successful, will the return pointer be the same as p
or will it be different.

I've just checked with a copy of the draft C89 standard and it says
that the return pointer could be either...

Of course. If you think about things in practical fashion (i.e.
implementation details) if it's possible to expand the existing memory
region in place by adjusting a number in a table or something, then it
makes sense to do so. If not, then it pretty much has to be moved.


Brian
Dec 20 '06 #10

P: n/a
subramanian wrote:
I have taken the following prototype from K & R.

void *realloc(void *p, size_t size);

Suppose p was earlier allocated by malloc. Suppose I am calling realloc
with larger size value.
If realloc is successful, will the return pointer be the same as p or
will it be different.
K & R 2nd edition says "realloc returns a pointer to the new space".

Why I am asking is that if they are different, the older pointer value
of p should be freed.
realloc can return one of two things: It either returns a null pointer,
or it returns a non-null pointer.

If realloc returns a null pointer, it has failed to reallocate the
memory; the situation is exactly the same as if you had never called
realloc. The old pointer is still valid, and it points to exactly as
much data as it held before.

If realloc returns a non-null pointer, it has reallocated the memory.
The old pointer is now invalid. You need not and you must not do
anything with it. You need not free it and you must not free it. Any
use of it is undefined behavior; even comparing with the new result is
undefined behavior. Here an example; you need to include the right
header files to make it proper C:

void* test_realloc (void* p, size_t new_size)
{
void* q = realloc (p, new_size);
if (q == NULL) {
printf ("realloc failed, p is unchanged.\n");
return p;
} else {
printf ("realloc was successful. Don't even look at p.\n");
return q;
}
}

Dec 20 '06 #11

P: n/a
"Default User" <de***********@yahoo.comwrites:
ma**********@pobox.com wrote:
>subramanian wrote:
I have taken the following prototype from K & R.

void *realloc(void *p, size_t size);

Suppose p was earlier allocated by malloc. Suppose I am calling
realloc with larger size value.
If realloc is successful, will the return pointer be the same as p
or will it be different.

I've just checked with a copy of the draft C89 standard and it says
that the return pointer could be either...


Of course. If you think about things in practical fashion (i.e.
implementation details) if it's possible to expand the existing memory
region in place by adjusting a number in a table or something, then it
makes sense to do so. If not, then it pretty much has to be moved.
But even a realloc() that shrinks the allocated space or leaves it the
same size *could* relocate it. It might never do so in some
implementations; on the other hand, relocating it might make room for
future allocations.

--
Keith Thompson (The_Other_Keith) 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.
Dec 21 '06 #12

P: n/a

Default User wrote:
ma**********@pobox.com wrote:

subramanian wrote:
I have taken the following prototype from K & R.
>
void *realloc(void *p, size_t size);
>
Suppose p was earlier allocated by malloc. Suppose I am calling
realloc with larger size value.
If realloc is successful, will the return pointer be the same as p
or will it be different.
I've just checked with a copy of the draft C89 standard and it says
that the return pointer could be either...


Of course. If you think about things in practical fashion (i.e.
implementation details) if it's possible to expand the existing memory
region in place by adjusting a number in a table or something, then it
makes sense to do so. If not, then it pretty much has to be moved.
I know that, but I feel that particularly in this group it's good to
refer to what the standard says, so you have some grounds for stating
things...

Dec 21 '06 #13

This discussion thread is closed

Replies have been disabled for this discussion.