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

Can realloc(p,0) return NULL when p is non-NULL and memory aplenty?

P: n/a
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>

int main(void)
{
void *p;
p = malloc(0);
if (p==NULL)
puts("malloc(0) returned NULL");
else
{
p = realloc(p,0);
if (p==NULL)
puts("realloc(p,0) returned NULL");
else
puts("realloc(p,0) did not return NULL");
}
return 0;
}
Mar 6 '08 #1
Share this Question
Share on Google+
9 Replies


P: n/a
Francois Grieu wrote:
When running the following code under MinGW, I get
realloc(p,0) returned NULL
Is that a non-conformance?
Whether malloc(0) returns NULL or a pointerr to 0 bytes is implementation
defined
I think the same is true for realloc(p, 0)

Bye, Jojo
Mar 6 '08 #2

P: n/a
In article <cb**********************************@m36g2000hse. googlegroups.com>,
Francois Grieu <fg****@gmail.comwrote:
>When running the following code under MinGW, I get
realloc(p,0) returned NULL
Is that a non-conformance?
No, it is conformance, and returning non-NULL would be non-conformance.

C89 4.10.3.4 The realloc Funciton

If size is zero and ptr is not a null pointer, the object
it points to is freed.

Returns

The realloc function returns either a null pointer or a
pointer to the possibly moved allocated space.
In the case of zero as the size, there is no more allocated space
(because zero size requires freeing), so the other branch of the
'either' kicks in, requiring realloc to return a null pointer
for this case.
--
amazon.com's top 8 books about "walter" are Kotzwinkle/ Gundy/ Colman's
"Walter the Farting Dog"
Mar 6 '08 #3

P: n/a
On Thu, 06 Mar 2008 18:03:02 +0000, Walter Roberson wrote:
In article
<cb**********************************@m36g2000hse. googlegroups.com>,
Francois Grieu <fg****@gmail.comwrote:
>>When running the following code under MinGW, I get realloc(p,0) returned
NULL
Is that a non-conformance?

No, it is conformance, and returning non-NULL would be non-conformance.

[C89 citation snipped]
While you're not at all wrong, please keep in mind that this is one of the
areas in which C99 differs from the previous standard. In C99, it's
unspecified whether realloc(p, 0) returns a null pointer, but if it
returns a null pointer, then p is *not* freed.
Mar 6 '08 #4

P: n/a
Harald van D?k wrote:
On Thu, 06 Mar 2008 18:03:02 +0000, Walter Roberson wrote:
>In article
<cb**********************************@m36g2000hse .googlegroups.com>,
Francois Grieu <fg****@gmail.comwrote:
>>When running the following code under MinGW, I get realloc(p,0)
returned NULL
Is that a non-conformance?

No, it is conformance, and returning non-NULL would be
non-conformance.

[C89 citation snipped]

While you're not at all wrong, please keep in mind that this is one
of the areas in which C99 differs from the previous standard. In C99,
it's unspecified whether realloc(p, 0) returns a null pointer, but if
it returns a null pointer, then p is *not* freed.
I don't read it mlike this

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.

allocating 0 bytes can't be too difficult ;-), so no compelling reason to
return NULL

Bye, Jojo

Mar 6 '08 #5

P: n/a
In article <da***************************@cache6.tilbu1.nb.ho me.nl>,
Harald van =?UTF-8?b?RMSzaw==?= <tr*****@gmail.comwrote:
>On Thu, 06 Mar 2008 18:03:02 +0000, Walter Roberson wrote:
>In article
<cb**********************************@m36g2000hse .googlegroups.com>,
Francois Grieu <fg****@gmail.comwrote:
>>>When running the following code under MinGW, I get realloc(p,0) returned
NULL
Is that a non-conformance?
>No, it is conformance, and returning non-NULL would be non-conformance.
>[C89 citation snipped]
>While you're not at all wrong, please keep in mind that this is one of the
areas in which C99 differs from the previous standard. In C99, it's
unspecified whether realloc(p, 0) returns a null pointer, but if it
returns a null pointer, then p is *not* freed.
Good point -- but as best I -recall- MinGW is not C99.

--
"Beware of bugs in the above code; I have only proved it correct,
not tried it." -- Donald Knuth
Mar 6 '08 #6

P: n/a
On Mar 6, 7:03 pm, rober...@ibd.nrc-cnrc.gc.ca (Walter Roberson)
wrote:
Francois Grieu <fgr...@gmail.comwrote:
>When running the following code under MinGW, I get
realloc(p,0) returned NULL
Is that a non-conformance?

No, it is conformance, and returning non-NULL would be non-conformance.
I disagree (at least) about the second member of that answer under
C99. IMHO realloc(p,0) is allowed to return the same thing as
malloc(0), which is not required to return NULL.

I reason that when p is a valid non-NULL pointer to a pointer returned
by malloc() and memory is aplenty, realloc(p,0) must return a pointer
to a new object that has the size 0, which is the same thing a what
malloc(0) should return, which is not required to be NULL, and is not
NULL in many implementations, including that one I'm strugling with.
C89 4.10.3.4 The realloc Function

If size is zero and ptr is not a null pointer, the object
it points to is freed.

Returns

The realloc function returns either a null pointer or a
pointer to the possibly moved allocated space.

In the case of zero as the size, there is no more allocated space
(because zero size requires freeing), so the other branch of the
'either' kicks in, requiring realloc to return a null pointer
for this case.

C99 says {
void *realloc(void *ptr, size_t size);

The realloc function deallocates the old object pointed to by ptr and
returns a pointer to a new object that has the size specified by size.
The contents of the new object shall be the same as that of the old
object prior to deallocation, up to the lesser of the new and old
sizes. Any bytes in the new object beyond the size of the old object
have indeterminate values.

If ptr is a null pointer, the realloc function behaves like the malloc
function for the specified size. Otherwise, if ptr does not match a
pointer earlier returned by the calloc, malloc, or realloc function,
or if the space has been deallocated by a call to the free or realloc
function, the behavior is undefined. If memory for the new object
cannot be allocated, the old object is not deallocated and its value
is unchanged.

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


I get the same result "realloc(p,0) returned NULL" with the source
changed to the deeper test:

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

int main(void)
{
void *p = malloc(1);
if (p==NULL)
puts("Memory is very low"); // does not occur
if (malloc(0)==NULL)
puts("malloc(0) returned NULL"); // does not occur
if (realloc(NULL,0)==NULL)
puts("realloc(NULL,0) returned NULL"); // does not occur
if (realloc(p,0)==NULL)
puts("realloc(p,0) returned NULL"); // occurs ?!
if (malloc(10000)==NULL)
puts("Memory was rather low"); // does not occur
}
So I get an implementation of realloc(ptr,0) that turns a NULL ptr to
a non-NULL result, and non-NULL ptr to NULL result; which is at the
very least a surprise, non-orthogonal, and error-prone. In my case a
perfectly sound-looking "read the whole file in memory, in several
chuncks as necessary" function failed for an empty file, claiming
there is no memory.

Francois Grieu
Mar 6 '08 #7

P: n/a
On Thu, 06 Mar 2008 19:31:30 +0100, Joachim Schmitz wrote:
Harald van D?k wrote:
>On Thu, 06 Mar 2008 18:03:02 +0000, Walter Roberson wrote:
>>In article
<cb**********************************@m36g2000hs e.googlegroups.com>,
Francois Grieu <fg****@gmail.comwrote:
When running the following code under MinGW, I get realloc(p,0)
returned NULL
Is that a non-conformance?

No, it is conformance, and returning non-NULL would be
non-conformance.

[C89 citation snipped]

While you're not at all wrong, please keep in mind that this is one of
the areas in which C99 differs from the previous standard. In C99, it's
unspecified whether realloc(p, 0) returns a null pointer, but if it
returns a null pointer, then p is *not* freed.
I don't read it mlike this

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.
7.20.3p1 applies to all allocation functions.
"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."

This allows realloc(p, 0) to unconditionally fail (since the text you
quoted specifies that a null pointer return value signifies failure for
realloc).
allocating 0 bytes can't be too difficult ;-)
<nit>realloc(p, 0), if it succeeded, hasn't allocated 0 bytes. It has
allocated one or more bytes, plus whatever information free needs to give
it back later.</nit>

Anyway, even if it weren't specifically allowed to always fail, it could
still for example fail on implementations where if the size is small,
*alloc returns pointers to pre-allocated buckets depending on the
requested size.
Mar 6 '08 #8

P: n/a
CBFalconer wrote:
<snip>
You also can't positively tell a malloc system error from success.
Probably not with standrd C, but AFAIK POSIX reqires malloc to set errno on
failure.
So if malloc() return NULL, lookup errno, if that is 0, no failure occured.

Bye, Jojo
Mar 7 '08 #9

P: n/a
CBFalconer <cb********@yahoo.comwrites:
Note that either a NULL or an individual pointer can be returned.
The pointer to a zero size space can't be dereferenced. You also
can't positively tell a malloc system error from success. So I
advise always allocating (or reallocing) 1 or more bytes.
While that's true, I'm not sure I see what practical use it would make
to be able to determine the difference between NULL returned because
of a system error, and NULL returned because you asked for either that
or an unusable pointer.

That being said, I agree about reallocing 1 or more bytes, since doing
0 without knowing that your pointer will be freed is pretty useless.

--
Micah J. Cowan
Programmer, musician, typesetting enthusiast, gamer...
http://micah.cowan.name/
Mar 7 '08 #10

This discussion thread is closed

Replies have been disabled for this discussion.