0

I have been writing code where data are allocated in many loops, and found using realloc() quite convenient for the purpose because it handles initial and mid-loop data consistently without adding conditions for freeing and allocating new pointers.

I wrote this little test program:

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

int main() {
    char *x = NULL;
    x = realloc (x, 0);
    printf ("Address of realloc (NULL, 0): %p\n", x);
    assert (x != NULL);
    printf ("Address of realloc (x, 8): %p\n", x);
    x = realloc (x, 8);
    assert (x != NULL);
    x = realloc (x, 0);
    assert (x == NULL);
    printf ("Address of realloc (x, 0): %p\n", x);
    x = realloc (x, 21);
    printf ("Address of realloc (x, 21): %p\n", x);
    assert (x != NULL);
    x = realloc (x, 0); // free.
    assert (x == NULL);
    printf ("Address of realloc (x, 0): %p\n", x);

    return 0;
}

And doing a memory check:

$ gcc -Wall -g test_realloc.c -o test_realloc.o
$ valgrind ./test_realloc.o 
==1192613== Memcheck, a memory error detector
==1192613== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==1192613== Using Valgrind-3.16.1 and LibVEX; rerun with -h for copyright info
==1192613== Command: ./test_realloc.o
==1192613== 
Address of realloc (NULL, 0): 0x4a3a040
Address of realloc (x, 8): 0x4a3a040
Address of realloc (x, 0): (nil)
Address of realloc (x, 21): 0x4a3a510
Address of realloc (x, 0): (nil)
==1192613== 
==1192613== HEAP SUMMARY:
==1192613==     in use at exit: 0 bytes in 0 blocks
==1192613==   total heap usage: 4 allocs, 4 frees, 1,053 bytes allocated
==1192613== 
==1192613== All heap blocks were freed -- no leaks are possible
==1192613== 
==1192613== For lists of detected and suppressed errors, rerun with: -s
==1192613== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

So far, great. The only caveat is that the initial value must be initialized (even to NULL).

Now I am wondering how portable this is across platforms. man 3 realloc on Linux x86_64 is pretty explicit about this behavior except for realloc (NULL, 0) which in this case, unexpectedly yields a non-NULL address.

How far can I rely on this behavior?

EDIT: Precisely, my question is whether I can rely on my sample program to be free of UB or memory leaks on any platform.

Thanks.

user3758232
  • 758
  • 5
  • 19
  • 2
    You can rely on the behavior of realloc, but you need to stop assuming that it will never return NULL. `assert` is not an error check. – William Pursell Jan 04 '21 at 17:45
  • Be aware that the `recalloc(ptr,0)` call to free memory is not in the C standard. – 12431234123412341234123 Jan 04 '21 at 17:55
  • @12431234123412341234123 from the man page: "if size is equal to zero, and ptr is not NULL, then the call is equivalent to free(ptr). " Shall I not rely on the man pages for portability? – user3758232 Jan 04 '21 at 17:58
  • Mostly I am concerned that my sample program ends up with no memory leak or UB on any platform. Whether `realloc (NULL, 0)` yields NULL or not, is indifferent as long as I don't rely on that. – user3758232 Jan 04 '21 at 18:00
  • @user3758232 It works on Linux. The C standard says the behaviour is implementation defined. As far as i understand the POSIX and C standard, i would even argue that the Linux implementation is not standard compliant. – 12431234123412341234123 Jan 04 '21 at 18:02
  • @user3758232: If you are looking at a Unix/POSIX man page, then it is documentation for Unix/POSIX. It is portable for Unix/POSIX. It is not documentation for C, and it is not portable for C. Unix adds a variety of characteristics to standard C functions. – Eric Postpischil Jan 04 '21 at 18:07
  • 1
    I have to correct myself: The behaviour of freeing it with a size of 0 is explicite requested by C89 but not in newer C standards. As far as i understand the newer standards and the POSIX standard it is even non-standard conform to free the pointer. TLDR: Do not use `realloc(somePointer,0);`. – 12431234123412341234123 Jan 04 '21 at 18:18
  • Related https://stackoverflow.com/questions/21672912/freeing-allocated-memory-realloc-vs-free?noredirect=1&lq=1 and https://stackoverflow.com/questions/16759849/using-realloc-x-0-instead-of-free-and-using-malloc-with-length-of-a-string – 12431234123412341234123 Jan 04 '21 at 18:35

4 Answers4

2

This is what the C11 standard (to be more precise, it's a draft but it's the closest thing to the standard that's publicly available) says:

Synopsis

    #include <stdlib.h>
    void *realloc(void *ptr, size_t size);

Description

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 a memory management 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.

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.

https://port70.net/~nsz/c/c11/n1570.html#7.22.3.4

So realloc (NULL, 0) is the same as malloc(0) which may return a non-null pointer that may not be dereferenced.

klutt
  • 30,332
  • 17
  • 55
  • 95
  • 2
    Looks like that is from the former standard, 2011. The 2018 standard has additional text. – Eric Postpischil Jan 04 '21 at 17:49
  • @12431234123412341234123: It is not non-conforming to free the space. I quoted the text from the 2018 C standard (official, not draft) in my answer, and it says it is implementation-defined whether the old object is deallocated. – Eric Postpischil Jan 04 '21 at 18:45
2

In asking about “this behavior,” your question is not specific about which behavior you are interested in. Presumably, you are interested in whether realloc may or may not return a null pointer for realloc(x, 0) and whether it will free the previously allocated space pointed to by x.

The answer to both of those questions is either is allowed but the C implementation must document which it does.

Null or non-null may be returned.

C 2018 7.22.3 1 says “… If the size of the space requested is zero, the behavior is implementation-defined: either a null pointer is returned to indicate an error, 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.” Implementation-defined means the implementation must document what it does, so this should be stated in the compiler and/or standard library documentation.

Space may be freed or not.

Regarding using realloc to free space, C 2018 7.22.3.5 3 says “… If size is zero and memory for the new object is not allocated, it is implementation-defined whether the old object is deallocated…”

Conclusions

To write portable code, do not use realloc to free all the space of an allocation. Use free.

To allocate “zero” space, either tolerate any return value from malloc (null or not) or always allocate at least one byte even though you do not need it.

Eric Postpischil
  • 195,579
  • 13
  • 168
  • 312
1

realloc(ptr, 0) is not equivalent to free(ptr)

To quote the standard (C18, §7.22.3.5 - IIRC, C11 hasn't changed):

The realloc function
Synopsis
1
#include <stdlib.h>
void *realloc(void *ptr, size_t size);

Description
2 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.
3 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 a memory management function, or if
the space has been deallocated by a call to the free or realloc function, the behavior is undefined.
If size is nonzero and memory for the new object is not allocated, the old object is not deallocated.
If size is zero and memory for the new object is not allocated, it is implementation-defined whether
the old object is deallocated. If the old object is not deallocated, its value shall be unchanged.
 
4 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 has not been allocated.

As you can see, it doesn't specify a special case for realloc calls where the size is 0. It explicitly states that what happens if you call realloc(ptr, 0), the behaviour is implementation defined.

That pretty much answers your question: using realloc instead of free is not something you can rely on.

Furthermore: assert(x != NULL) is test code. Whenever allocating memory, you really ought to check:

if (x == NULL) {}

The behaviour you see happens to be how GCC chose to implement the spec, but it cannot be relied upon.

link to C18 standard

Elias Van Ootegem
  • 74,482
  • 9
  • 111
  • 149
1

TL;DR: No. Don't use realloc(somePointer,0).

It looks like realloc(somePointer,0) changed between different C standards. From C89 [1]:

... If ptr is a null pointer, the realloc function behaves like the malloc function for the specified size. ... If the space cannot be allocated, the object pointed to by ptr is unchanged. If size is zero and ptr is not a null pointer, the object it points to is freed.

But this not the case anymore in the newer C standards.

From the POSIX man page [2]:

The description of realloc() has been modified from previous versions of this standard to align with the ISO/IEC 9899:1999 standard. Previous versions explicitly permitted a call to realloc(p, 0) to free the space pointed to by p and return a null pointer. While this behavior could be interpreted as permitted by this version of the standard, the C language committee have indicated that this interpretation is incorrect. Applications should assume that if realloc() returns a null pointer, the space pointed to by p has not been freed. Since this could lead to double-frees, implementations should also set errno if a null pointer actually indicates a failure, and applications should only free the space if errno was changed.

[1] http://port70.net/~nsz/c/c89/c89-draft.html#4.10.3.4

[2] https://pubs.opengroup.org/onlinepubs/9699919799/functions/realloc.html

12431234123412341234123
  • 2,732
  • 15
  • 22