473,320 Members | 1,853 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,320 software developers and data experts.

when can realloc fail?

Hi,
I just want to get this right.
A call to realloc() will return NULL on error and the original memory
is left untouched,
both when requesting a larger or a smaller size that the original,
right?
But a call to realloc() with size set to zero is equivalent to free(),
with returns void.
Does that mean that a call to realloc() can fail when shinking memory
except when
shrinking it to zero in which case it will always succeed?

Thanks!

Apr 1 '07 #1
31 12667
ba******@hushmail.com wrote:
Hi,
I just want to get this right.
A call to realloc() will return NULL on error and the original memory
is left untouched,
both when requesting a larger or a smaller size that the original,
right?
But a call to realloc() with size set to zero is equivalent to free(),
with returns void.
Does that mean that a call to realloc() can fail when shinking memory
except when
shrinking it to zero in which case it will always succeed?
Yes, realloc() can fail when shrinking an allocation, or
when growing it, or even when leaving its size unchanged.

When reallocating to zero size, the situation is complicated.
C90 says "If size is zero and ptr is not a null pointer, the
object it points to is freed." Since free() cannot fail (given
an argument that doesn't invoke undefined behavior), it follows
that realloc(...,0) cannot fail.

But C99 has no such text, and makes no special case for size
zero. All we're told is that realloc(...,0) either fails or it
returns a pointer to an object of size zero. Nothing I can find
in C99 forbids realloc(...,0) to fail, so presumably it can.

--
Eric Sosman
es*****@acm-dot-org.invalid
Apr 1 '07 #2
ba******@hushmail.com wrote:
Hi,
I just want to get this right.
A call to realloc() will return NULL on error
The word failure might be more appropriate in this context than the
word error.
and the original memory is left untouched,
both when requesting a larger or a smaller size that the original, right?
Yes.
But a call to realloc() with size set to zero is equivalent to free(),
Semantically yes.
with returns void.
No, it returns an indeterminate value.
Does that mean that a call to realloc() can fail when shinking memory except when
shrinking it to zero in which case it will always succeed?
No. realloc is not guaranteed to suceed even when the new size is zero.

Apr 1 '07 #3
On Apr 1, 9:06 pm, Eric Sosman <esos...@acm-dot-org.invalidwrote:
banan...@hushmail.com wrote:
Hi,
I just want to get this right.
A call to realloc() will return NULL on error and the original memory
is left untouched,
both when requesting a larger or a smaller size that the original,
right?
But a call to realloc() with size set to zero is equivalent to free(),
with returns void.
Does that mean that a call to realloc() can fail when shinking memory
except when
shrinking it to zero in which case it will always succeed?

Yes, realloc() can fail when shrinking an allocation, or
when growing it, or even when leaving its size unchanged.

When reallocating to zero size, the situation is complicated.
C90 says "If size is zero and ptr is not a null pointer, the
object it points to is freed." Since free() cannot fail (given
an argument that doesn't invoke undefined behavior), it follows
that realloc(...,0) cannot fail.

But C99 has no such text, and makes no special case for size
zero. All we're told is that realloc(...,0) either fails or it
returns a pointer to an object of size zero. Nothing I can find
in C99 forbids realloc(...,0) to fail, so presumably it can.
Thank you for your reply!
But I wonder, if realloc(...,0) fails in C99, how can I know that?
How can I know if a returned NULL means that realloc() failed,
or if it is the pointer to the new memory, empty, which is NULL.
(That is what I got on my compiler anyway)

Apr 1 '07 #4
On Apr 1, 9:07 pm, "santosh" <santosh....@gmail.comwrote:
banan...@hushmail.com wrote:
Hi,
I just want to get this right.
A call to realloc() will return NULL on error

The word failure might be more appropriate in this context than the
word error.
and the original memory is left untouched,
both when requesting a larger or a smaller size that the original, right?

Yes.
But a call to realloc() with size set to zero is equivalent to free(),

Semantically yes.
with returns void.

No, it returns an indeterminate value.
What? My manpage says "void free(void *ptr);",
doesn't free return void? By that I meant, free doesn't return
anything.
Does that mean that a call to realloc() can fail when shinking memory except when
shrinking it to zero in which case it will always succeed?

No. realloc is not guaranteed to suceed even when the new size is zero.
And as I wrote in the other post, I wonder how I can know that.

Apr 1 '07 #5
<ba******@hushmail.comha scritto nel messaggio
news:11*********************@y66g2000hsf.googlegro ups.com...
Does that mean that a call to realloc() can fail when shinking memory
except when
shrinking it to zero in which case it will always succeed?

No. realloc is not guaranteed to suceed even when the new size is zero.

And as I wrote in the other post, I wonder how I can know that.
Can't you just use free()?
Apr 1 '07 #6
ba******@hushmail.com wrote:
On Apr 1, 9:07 pm, "santosh" <santosh....@gmail.comwrote:
banan...@hushmail.com wrote:
Hi,
I just want to get this right.
A call to realloc() will return NULL on error
The word failure might be more appropriate in this context than the
word error.
and the original memory is left untouched,
both when requesting a larger or a smaller size that the original, right?
Yes.
But a call to realloc() with size set to zero is equivalent to free(),
Semantically yes.
with returns void.
No, it returns an indeterminate value.

What? My manpage says "void free(void *ptr);",
doesn't free return void? By that I meant, free doesn't return
anything.
You're correct. But realloc with a new size of zero either returns a
null pointer, upon failure, or returns an indeterminate value.
Does that mean that a call to realloc() can fail when shinking memory except when
shrinking it to zero in which case it will always succeed?
No. realloc is not guaranteed to suceed even when the new size is zero.

And as I wrote in the other post, I wonder how I can know that.
If the reallocation to zero size suceeds, an indeterminate pointer
value is returned, if it fails, a null pointer value is returned and
the original block is unchanged.

Apr 1 '07 #7
ba******@hushmail.com writes:
But I wonder, if realloc(...,0) fails in C99, how can I know that?
I asked on comp.std.c recently. In C99, realloc returns NULL if and
only if it fails. You'll see it if you read the C99 text without
expecting compatibliity with the C89 realloc(,0) behavior.
How can I know if a returned NULL means that realloc() failed,
or if it is the pointer to the new memory, empty, which is NULL.
Just avoid realloc(, 0).

In theory, you can check '#if __STDC_VERSION__ >= 199901L' to see if you
have a C99 compiler. In practice, that doesn't tell you if you have a
C99 _library_: You might have a compiler like gcc which has both C99 and
C89 mode, but uses the system C library in either case.

--
Regards,
Hallvard
Apr 1 '07 #8
On Apr 1, 10:17 pm, "santosh" <santosh....@gmail.comwrote:
banan...@hushmail.com wrote:
On Apr 1, 9:07 pm, "santosh" <santosh....@gmail.comwrote:
banan...@hushmail.com wrote:
Hi,
I just want to get this right.
A call to realloc() will return NULL on error
The word failure might be more appropriate in this context than the
word error.
and the original memory is left untouched,
both when requesting a larger or a smaller size that the original, right?
Yes.
But a call to realloc() with size set to zero is equivalent to free(),
Semantically yes.
with returns void.
No, it returns an indeterminate value.
What? My manpage says "void free(void *ptr);",
doesn't free return void? By that I meant, free doesn't return
anything.

You're correct. But realloc with a new size of zero either returns a
null pointer, upon failure, or returns an indeterminate value.
Does that mean that a call to realloc() can fail when shinking memory except when
shrinking it to zero in which case it will always succeed?
No. realloc is not guaranteed to suceed even when the new size is zero.
And as I wrote in the other post, I wonder how I can know that.

If the reallocation to zero size suceeds, an indeterminate pointer
value is returned, if it fails, a null pointer value is returned and
the original block is unchanged.
In that case there is something strange here, if I compile this in gcc

#include <stdio.h>
#include <stdlib.h>

int main(void)
{
char *ptr = malloc(42);
if (realloc(ptr, 0) == NULL)
printf("realloc failed\n");
return 0;
}

I always get "realloc failed" printed, in both c89 and c99 mode.
I wouldn't expect it everytime as it does here.
Anyway, I will use free() instead, to avoid confusion.
Thanks for the help!
Apr 1 '07 #9
On 1 Apr 2007 11:50:05 -0700, ba******@hushmail.com wrote:
>Hi,
I just want to get this right.
A call to realloc() will return NULL on error and the original memory
is left untouched,
both when requesting a larger or a smaller size that the original,
right?
It returns NULL if the space cannot be allocated. Whether it is due
to an error or not is something else.
>But a call to realloc() with size set to zero is equivalent to free(),
with returns void.
No it is not. Read the last sentence of 7.20.3 again.
>Does that mean that a call to realloc() can fail when shinking memory
except when
shrinking it to zero in which case it will always succeed?
No. Success is not guaranteed.
>
Thanks!

Remove del for email
Apr 1 '07 #10
<ba******@hushmail.comwrote in message
Hi,
I just want to get this right.
A call to realloc() will return NULL on error and the original memory
is left untouched,
both when requesting a larger or a smaller size that the original,
right?
But a call to realloc() with size set to zero is equivalent to free(),
with returns void.
Does that mean that a call to realloc() can fail when shinking memory
except when
shrinking it to zero in which case it will always succeed?
It is a bit of a grey area.

Normally you want the construct

temp = realloc(ptr, newsize);
if(temp == 0)
{
fprintf(stderr, "Oh no, out of memory\n");
free(ptr);
return -1;
}
ptr = temp;
..... /* do something useful */
free(ptr);
return 0;

it is quite a lot of code simply to perform memory management. However if
newsize is zero you've entered a grey area. temp could be zero or a valid
pointer assuming that the function doesn't fail. If we say that realloc()
must return a pointer to a block of no memory then you've also got the
potential for a fail. Then it is not unlikely that your code, knowing that
newsize is zero and it is working on an empty data set, will forget to call
free() on ptr.
--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm
Apr 1 '07 #11
On Apr 2, 8:17 am, "santosh" <santosh....@gmail.comwrote:
But realloc with a new size of zero either returns a
null pointer, upon failure, or returns an indeterminate value.
I don't see any text in the standard to support this.

In fact, it seems absurd, as undefined behaviour would
be caused as soon as the user checked or stored the
return value.

The text in 7.20.3.4 in C99 only says that the items pointed
to by the return value are indeterminate.

Apr 1 '07 #12
Old Wolf wrote:
>
On Apr 2, 8:17 am, "santosh" <santosh....@gmail.comwrote:
But realloc with a new size of zero either returns a
null pointer, upon failure, or returns an indeterminate value.

I don't see any text in the standard to support this.
There isn't.
realloc returns either a null pointer or a pointer to memory.

--
pete
Apr 1 '07 #13
ba******@hushmail.com wrote:
On Apr 1, 9:06 pm, Eric Sosman <esos...@acm-dot-org.invalidwrote:
>banan...@hushmail.com wrote:
<snip>
>>A call to realloc() will return NULL on error and the original memory
is left untouched,
both when requesting a larger or a smaller size that the original,
right?
But a call to realloc() with size set to zero is equivalent to free(),
with returns void.
Does that mean that a call to realloc() can fail when shinking memory
except when
shrinking it to zero in which case it will always succeed?
<snip>
> But C99 has no such text, and makes no special case for size
zero. All we're told is that realloc(...,0) either fails or it
returns a pointer to an object of size zero. Nothing I can find
in C99 forbids realloc(...,0) to fail, so presumably it can.

Thank you for your reply!
But I wonder, if realloc(...,0) fails in C99, how can I know that?
How can I know if a returned NULL means that realloc() failed,
or if it is the pointer to the new memory, empty, which is NULL.
(That is what I got on my compiler anyway)
In C99 it only returns NULL when it fails. If it returns non-null
and the size is 0 then it will return an address to a block of
memory of zero size. The address *will not be NULL* and you will
have to free it using free().

--
Ioan - Ciprian Tandau
tandau _at_ freeshell _dot_ org (hope it's not too late)
(... and that it still works...)
Apr 2 '07 #14
ba******@hushmail.com wrote:
>
.... snip ...
>
In that case there is something strange here, if I compile this in gcc

#include <stdio.h>
#include <stdlib.h>

int main(void)
{
char *ptr = malloc(42);
if (realloc(ptr, 0) == NULL)
printf("realloc failed\n");
return 0;
}
That depends on your library, not gcc. I consider libraries that
do that as poorly implemented, although legal.

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>

--
Posted via a free Usenet account from http://www.teranews.com

Apr 2 '07 #15
Nelu wrote:
>
.... snip ...
>
In C99 it only returns NULL when it fails. If it returns non-null
and the size is 0 then it will return an address to a block of
memory of zero size. The address *will not be NULL* and you will
have to free it using free().
Not so. C99 specifically allows a successfull realloc(p, 0) or
malloc(0) to return NULL. I consider systems that use this to be
flawed, yet portable code has to allow for it.

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>
--
Posted via a free Usenet account from http://www.teranews.com

Apr 2 '07 #16
CBFalconer wrote:
Nelu wrote:
... snip ...
>In C99 it only returns NULL when it fails. If it returns non-null
and the size is 0 then it will return an address to a block of
memory of zero size. The address *will not be NULL* and you will
have to free it using free().

Not so. C99 specifically allows a successfull realloc(p, 0) or
malloc(0) to return NULL. I consider systems that use this to be
flawed, yet portable code has to allow for it.
Could you point out where this is allowed? I can see
that it's permitted for realloc(NULL, 0), but can't find any
such dispensation for realloc(p, 0) where p!=NULL.

--
Eric Sosman
es*****@acm-dot-org.invalid
Apr 2 '07 #17
Eric Sosman wrote:
>
CBFalconer wrote:
Nelu wrote:
... snip ...
In C99 it only returns NULL when it fails. If it returns non-null
and the size is 0 then it will return an address to a block of
memory of zero size. The address *will not be NULL* and you will
have to free it using free().
Not so. C99 specifically allows a successfull realloc(p, 0) or
malloc(0) to return NULL. I consider systems that use this to be
flawed, yet portable code has to allow for it.

Could you point out where this is allowed? I can see
that it's permitted for realloc(NULL, 0), but can't find any
such dispensation for realloc(p, 0) where p!=NULL.
N869
7.20.3 Memory management functions
[#1]

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.

--
pete
Apr 2 '07 #18
CBFalconer wrote:
Nelu wrote:
.... snip ...
>In C99 it only returns NULL when it fails. If it returns non-null
and the size is 0 then it will return an address to a block of
memory of zero size. The address *will not be NULL* and you will
have to free it using free().

Not so. C99 specifically allows a successfull realloc(p, 0) or
malloc(0) to return NULL. I consider systems that use this to be
flawed, yet portable code has to allow for it.
Where?

n1124:
7.20.3.3-4
Returns:
"The realloc function returns a pointer to the new object (which
may have the same
value as a pointer to the old object), or a null pointer if the
new object could not be
allocated."

Now, *malloc* is different: "The malloc function returns either a
null pointer or a pointer to the allocated space.". I think this
means that it will have to return NULL if it fails (a non-null
pointer must point to the allocated space, but the allocation
failed), but it could probably be successful in allocating space
and still return NULL.

7.20.3-1 says:
"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."
So, yes, realloc(.., 0) can return NULL but the definition of
realloc forces specifies NULL as failure to allocate the new
object. On malloc there's no such specification.
--
Ioan - Ciprian Tandau
tandau _at_ freeshell _dot_ org (hope it's not too late)
(... and that it still works...)
Apr 2 '07 #19
Nelu wrote:
Now, *malloc* is different: "The malloc function returns either a
null pointer or a pointer to the allocated space.". I think this
means that it will have to return NULL if it fails (a non-null
pointer must point to the allocated space, but the allocation
failed), but it could probably be successful in allocating space
and still return NULL.
malloc can't be successful in allocating space
and still return NULL.

--
pete
Apr 2 '07 #20
pete wrote:
Nelu wrote:
>Now, *malloc* is different: "The malloc function returns either a
null pointer or a pointer to the allocated space.". I think this
means that it will have to return NULL if it fails (a non-null
pointer must point to the allocated space, but the allocation
failed), but it could probably be successful in allocating space
and still return NULL.

malloc can't be successful in allocating space
and still return NULL.
Why not? 7.20.3 only says that the functions return NULL if space
for the object could not be allocated. It doesn't say anything
about successful allocation. I understand the fact returning NULL
on successful allocations will lead to memory leaks, probably,
but I couldn't find anything related to that in the standard.

--
Ioan - Ciprian Tandau
tandau _at_ freeshell _dot_ org (hope it's not too late)
(... and that it still works...)
Apr 2 '07 #21
Nelu wrote:
>
pete wrote:
malloc can't be successful in allocating space
and still return NULL.

Why not? 7.20.3 only says that the functions return NULL if space
for the object could not be allocated. It doesn't say anything
about successful allocation.
Read harder!

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.

--
pete
Apr 2 '07 #22
pete wrote:
Nelu wrote:
>pete wrote:
>>malloc can't be successful in allocating space
and still return NULL.
Why not? 7.20.3 only says that the functions return NULL if space
for the object could not be allocated. It doesn't say anything
about successful allocation.

Read harder!

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.
I read those lines but I think I misunderstood them. I was
thinking that NULL satisfies the conditions but "... 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)" shows I was wrong about this.

Thanks!
--
Ioan - Ciprian Tandau
tandau _at_ freeshell _dot_ org (hope it's not too late)
(... and that it still works...)
Apr 2 '07 #23
Eric Sosman wrote:
CBFalconer wrote:
>Nelu wrote:
... snip ...
>>In C99 it only returns NULL when it fails. If it returns non-null
and the size is 0 then it will return an address to a block of
memory of zero size. The address *will not be NULL* and you will
have to free it using free().

Not so. C99 specifically allows a successfull realloc(p, 0) or
malloc(0) to return NULL. I consider systems that use this to be
flawed, yet portable code has to allow for it.

Could you point out where this is allowed? I can see
that it's permitted for realloc(NULL, 0), but can't find any
such dispensation for realloc(p, 0) where p!=NULL.
Penultimate sentence.

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.
--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>

--
Posted via a free Usenet account from http://www.teranews.com

Apr 2 '07 #24
CBFalconer wrote:
Eric Sosman wrote:
>CBFalconer wrote:
>>Nelu wrote:
... snip ...
In C99 it only returns NULL when it fails. If it returns non-null
and the size is 0 then it will return an address to a block of
memory of zero size. The address *will not be NULL* and you will
have to free it using free().
Not so. C99 specifically allows a successfull realloc(p, 0) or
malloc(0) to return NULL. I consider systems that use this to be
flawed, yet portable code has to allow for it.
Could you point out where this is allowed? I can see
that it's permitted for realloc(NULL, 0), but can't find any
such dispensation for realloc(p, 0) where p!=NULL.

Penultimate sentence.

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.
Do we read the penultimate sentence, and the ultimate one as ambivalent
on whether NULL is returned but that the allocation is freed in any
case? I do.

--
Joe Wright
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein ---
Apr 2 '07 #25
pete wrote:
Old Wolf wrote:
>On Apr 2, 8:17 am, "santosh" <santosh....@gmail.comwrote:
>>But realloc with a new size of zero either returns a
null pointer, upon failure, or returns an indeterminate value.
I don't see any text in the standard to support this.

There isn't.
realloc returns either a null pointer or a pointer to memory.
I have posed a question a little upthread: Given ptr points to an area
to be freed, and then 'realloc(ptr, 0);'. Granted that realloc can
return NULL or not, will the allocation of ptr be freed? I'd like to
think so.

--
Joe Wright
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein ---
Apr 2 '07 #26
Joe Wright wrote:
>
.... snip ...
>
I have posed a question a little upthread: Given ptr points to an
area to be freed, and then 'realloc(ptr, 0);'. Granted that realloc
can return NULL or not, will the allocation of ptr be freed? I'd
like to think so.
You don't know, which is one more reason to consider such
allocaters to be brain-dead.

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>

--
Posted via a free Usenet account from http://www.teranews.com

Apr 3 '07 #27
Joe Wright wrote:
CBFalconer wrote:
.... snip ...
>
> 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.

Do we read the penultimate sentence, and the ultimate one as
ambivalent on whether NULL is returned but that the allocation
is freed in any case? I do.
Which is one of the reasons I consider implementations that can
return NULL for a 0 size allocation to be brain damaged. The
allocator need only increment a 0 size request.

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>

--
Posted via a free Usenet account from http://www.teranews.com

Apr 3 '07 #28
CBFalconer wrote:
>
Joe Wright wrote:
... snip ...

I have posed a question a little upthread: Given ptr points to an
area to be freed, and then 'realloc(ptr, 0);'. Granted that realloc
can return NULL or not, will the allocation of ptr be freed? I'd
like to think so.

You don't know, which is one more reason to consider such
allocaters to be brain-dead.
N869
7.20.3.4 The realloc function
[#2] The realloc function deallocates the old object pointed
to by ptr

--
pete
Apr 3 '07 #29
CBFalconer wrote:
Joe Wright wrote:
>CBFalconer wrote:
... snip ...
>> 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.
Do we read the penultimate sentence, and the ultimate one as
ambivalent on whether NULL is returned but that the allocation
is freed in any case? I do.

Which is one of the reasons I consider implementations that can
return NULL for a 0 size allocation to be brain damaged. The
allocator need only increment a 0 size request.
As free(ptr) has no case for failure, we don't (can't!) check it. If
realloc(ptr, 0) will 'free' ptr then we need not check or care the
return from realloc in this case. One might define..

void Free(void *ptr) {
realloc(ptr, 0);
}

...without caring the return value of realloc.

--
Joe Wright
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein ---
Apr 3 '07 #30
Joe Wright wrote:
CBFalconer wrote:
>Joe Wright wrote:
>>CBFalconer wrote:
... snip ...
>>> 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.

Do we read the penultimate sentence, and the ultimate one as
ambivalent on whether NULL is returned but that the allocation
is freed in any case? I do.

Which is one of the reasons I consider implementations that can
return NULL for a 0 size allocation to be brain damaged. The
allocator need only increment a 0 size request.
As free(ptr) has no case for failure, we don't (can't!) check it. If
realloc(ptr, 0) will 'free' ptr then we need not check or care the
return from realloc in this case. One might define..

void Free(void *ptr) {
realloc(ptr, 0);
}

..without caring the return value of realloc.
Wrong attack. The only way to get it under control is to test the
argument before calling, and proceed from there:

void *Realloc(void *p, size_t sz) {
if (!sz) sz++;
return realloc(p, sz);
}

and similarly for malloc and calloc. Now you know that a NULL
return means failure.

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>

--
Posted via a free Usenet account from http://www.teranews.com

Apr 4 '07 #31
CBFalconer wrote:
Joe Wright wrote:
... snip ...
>I have posed a question a little upthread: Given ptr points to an
area to be freed, and then 'realloc(ptr, 0);'. Granted that realloc
can return NULL or not, will the allocation of ptr be freed? I'd
like to think so.

You don't know, which is one more reason to consider such
allocaters to be brain-dead.
The question isn't so much about implementations, but
about what the Standard requires/allows. In the passage
you and pete pointed out, the Standard allows realloc(p,0)
to return NULL or non-NULL at the implementation's whim.
If it returns NULL, the programmer has no way to distinguish
failure from success. (The dodge of changing zero to one is
clever, but the cure is worse than the disease: You get a
reliable success/failure indication, but at the price of
either failing unnecessarily or creating a memory leak.)

It seems to me the Standard could have defined realloc(p,0)
as equivalent to (free(p), (void*)NULL), but neither C90 nor
C99 actually chose to do so. (C90 had the free() equivalence
but didn't specify the returned value; C99 describes the
returned value but removes the free() language.)

The Rationale claims that realloc(p,0) *does* free the
memory pointed to by p, basing the claim on the deallocation
of the old object. But since the NULL return is overloaded
to mean both "failure" and "success: nothing allocated," the
programmer is stuck with a diagnostic problem.

Suggested work-around: Don't call realloc() with the second
argument equal to zero. That is, call realloc() to grow a
memory area or to shrink it, but avoid shrinking it to nothing.
If you want to free memory, use free().

--
Eric Sosman
es*****@acm-dot-org.invalid
Apr 4 '07 #32

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

11
by: Eitan Michaelson | last post by:
Hi, Can any one tell me what's wrong with this code? It leaks (acceding to bound checker), when it attempts to reallocate memory. The code is not pure C, but with minor adjustments any C...
9
by: mordac | last post by:
Hi, writing a heap ADT, need to handle insertion into the heap when it is full. Attempting to use realloc to do this, but realloc is changing the contents of my heap! The following is my...
2
by: collinm | last post by:
hi i expect to find 7 file on a folder... maybe less, maybe more... i can surely put this number to 1... but i think doing some realloc will be expensive... after 7 files, i need to use...
86
by: Walter Roberson | last post by:
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...
12
by: subramanian | last post by:
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...
29
by: marvinla | last post by:
Hello! I'm a beginner in C, and I'm having trouble with a pointer-to-pointer reallocation. This piece of code works well, but Valkyrie warns some parts (pointed below), and is breaking my real...
9
by: Francois Grieu | last post by:
When running the following code under MinGW, I get realloc(p,0) returned NULL Is that a non-conformance? TIA, Francois Grieu #include <stdio.h> #include <stdlib.h>
6
by: lithiumcat | last post by:
Hi, maybe you remember me, some time ago I asked about how to store an integer value into a void*, and I learned that doing pointer arithmetic yeilding a pointer outside of an object (except the...
35
by: Bill Cunningham | last post by:
My string.h headers declares two functions I have been using called memfrob and strfry. They are encryption types functions. My man pages say they are standard to linux c and gnu c. They sure...
0
by: DolphinDB | last post by:
The formulas of 101 quantitative trading alphas used by WorldQuant were presented in the paper 101 Formulaic Alphas. However, some formulas are complex, leading to challenges in calculation. Take...
0
by: ryjfgjl | last post by:
ExcelToDatabase: batch import excel into database automatically...
0
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
1
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
0
by: Vimpel783 | last post by:
Hello! Guys, I found this code on the Internet, but I need to modify it a little. It works well, the problem is this: Data is sent from only one cell, in this case B5, but it is necessary that data...
0
by: jfyes | last post by:
As a hardware engineer, after seeing that CEIWEI recently released a new tool for Modbus RTU Over TCP/UDP filtering and monitoring, I actively went to its official website to take a look. It turned...
0
by: CloudSolutions | last post by:
Introduction: For many beginners and individual users, requiring a credit card and email registration may pose a barrier when starting to use cloud servers. However, some cloud server providers now...
0
by: af34tf | last post by:
Hi Guys, I have a domain whose name is BytesLimited.com, and I want to sell it. Does anyone know about platforms that allow me to list my domain in auction for free. Thank you
0
by: Faith0G | last post by:
I am starting a new it consulting business and it's been a while since I setup a new website. Is wordpress still the best web based software for hosting a 5 page website? The webpages will be...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.