3

From http://en.cppreference.com/w/c/memory/malloc :

The returned pointer must be deallocated with free() or realloc().

From http://en.cppreference.com/w/c/memory/calloc :

The returned pointer must be deallocated with free() or realloc().

Strictly speaking, why must the returning pointer be deallocated?

Now I know that POSIX mandates the memory will be freed upon program termination so in practice calling malloc and terminating immediately will not do any harm. But that's not what I'm asking about.

Is this hard requirement ("MUST be deallocated") present in the C Standard, or is this an invention of cppreference contributors, to urge programmers not to leak memory? If such a hard requirement is present in the Standard, does this mean that, as per the C Standard (POSIX and other OS related things aside!), the program is UB if a pointer returned by malloc is not free'd, or does the Standard define consequences of failing to meet this requirement? (This would be particularly interesting, because this would possibly mean that the Standard deals with what happens when the program has already terminated!)

  • 2
    In some applications, embedded that never terminates, it might be that you call malloc(), but never free() to build up internal data-structures that will live forever, or rather until somebody pulls the power-cord. So in that case it would be impossible to fulfill a _requirement_ to free an allocated block of memory – user1048576 Oct 13 '17 at 17:16
  • 2
    I have always read that statement as saying "If you want to free the memory, you must do so using `free()` or `realloc()`". – Steve Summit Oct 13 '17 at 17:21
  • 1
    I think the emphasis is not in the ”must”, but in ”free”. When the block is freed, one must use the function `free`. – Aki Suihkonen Oct 13 '17 at 17:22
  • See also answers at [Should I free memory before exit?](https://stackoverflow.com/questions/36584062), – Steve Summit Oct 13 '17 at 17:24
  • The cited passages do not present in the C standard. I couldn't find anything similar either. – Eugene Sh. Oct 13 '17 at 17:27

5 Answers5

8

When they say "the returned pointer must be deallocated with free" on cppreference.com, they don't mean that as imperative that the programmer must do. It's meant more as "when the allocated memory is deallocated, it must be done with free or realloc because only those functions will do it correctly." There is no such imperative in the actual spec.

mnistic
  • 10,866
  • 2
  • 19
  • 33
0

C does not require you to free() the memory after allocation.

The side-effect is a memory leak. But you will not see any errors or warnings ever. This is your job as the programmer to fix.

Burstful
  • 347
  • 1
  • 10
0

No, there is absolutely no requirement to free any memory. Doing so is for your own sake, to allow the implementation to use it again for satisfying future calls to malloc.

Also, C has nothing to say about the state of your machine/OS outside of the C program or after it terminates. Specifying this is up to the OS or the standard governing it, and in practice for any multiprocess OS, memory obtained by malloc and other similar resources all go away on process termination.

R.. GitHub STOP HELPING ICE
  • 208,859
  • 35
  • 376
  • 711
  • I agree the C standard does not require you to free memory, but the comment that it has nothing to say about the state of your machine after your program terminates is irrelevant to figuring this out. The C standard could specify that a program that terminates without freeing allocated memory generates some error message or that its behavior upon exit is undefined, et cetera. That is, the standard could, theoretically, impose a requirement to free memory without imposing any post-termination requirement. – Eric Postpischil Nov 05 '17 at 04:00
  • @EricPostpischil: The second paragraph is more addressing the common misconception that "relying on the OS to free everything when your program ends" being "not portable" matters. The first paragraph already addressed the lack of any requirement to `free`. – R.. GitHub STOP HELPING ICE Nov 05 '17 at 17:05
  • @EricPostpischil: I used to code for a platform for which forgetting to call `free` would indeed leak memory at the OS level. – Joshua Feb 22 '22 at 20:30
0

The sentence The returned pointer must be deallocated with free() or realloc() does not exist in the C11 standard draft n1570.

Strictly speaking, the standard doesn't say that the object must be freed at all. It does not even say explicitly that the memory block needs to be freed by either free or realloc - it is just that the standard does not provide any other functions that could used to deallocate the space.

But also, it is not guaranteed that they're freed on program exit either - on the contrary, all the language opens up for the possibility that a program that is entered via main can still leak memory by not calling free, and still be running on a conforming implementation. The standard says in 6.2.4p2:

2 The lifetime of an object is the portion of program execution during which storage is guaranteed to be reserved for it. An object exists, has a constant address,33) and retains its last-stored value throughout its lifetime.34) If an object is referred to outside of its lifetime, the behavior is undefined. The value of a pointer becomes indeterminate when the object it points to (or just past) reaches the end of its lifetime.

and in 7.22.3p1:

The lifetime of an allocated object extends from the allocation until the deallocation.

That's it. The C standard isn't concerned with anything that happens after the program execution has been terminated. It is behaviour undefined by omission, so either possible behaviour is standard-conforming.

Antti Haapala -- Слава Україні
  • 129,958
  • 22
  • 279
  • 321
-1

While realloc() and free() would be the most natural ways of releasing memory in C, the most natural way of releasing memory in C++ is delete. Although the linked pages describe the behavior in C, the language is parallel to a pages which describes the behavior in C++:

On success, returns the pointer to the beginning of newly allocated memory. The returned pointer must be deallocated with std::free() or std::realloc().

I suspect the intended purpose of the text describing C++ is to make clear that other means of releasing storage, including delete, are not suitable for use with storage received from std::malloc or std::calloc; the same text appears in describing C even though C lacks any other means that would be expected to work.

supercat
  • 77,689
  • 9
  • 166
  • 211
  • I don't know, perhaps someone would have the idea to use `munmap` or `sbrk` with a negative value instead of `free`? I'd find this unlikely, though –  Oct 13 '17 at 19:57
  • @gaazkam: Implementations may provide other means of releasing memory, but free and realloc() are the only two provide by the Standard. – supercat Oct 15 '17 at 21:41
  • Using sbrk after malloc specifically causes undefined behavior: http://pubs.opengroup.org/onlinepubs/7908799/xsh/brk.html – mnistic Oct 16 '17 at 13:54
  • @mnistic: That's an issue for Unix or other systems that implement sbrk; the C Standard says nothing about such functions. – supercat Oct 16 '17 at 14:09
  • @supercat Of course, that's why it's a bad idea to mix the two to begin with, but the good folks at The Open Group made sure to spell it out – mnistic Oct 16 '17 at 14:13
  • On the flip side, implementations might usefully provide other functions that can safely be used to release memory obtained from `malloc`. For example, an implementation could offer mark/release functions such that calling `release` would free all blocks allocated after a `mark`. Such functions may be able to offer stronger guarantees about fragmentation than would be available when using only `malloc`/`free`, while allowing code using them to be compatible with libraries that expect to use the latter. – supercat Oct 16 '17 at 15:13
  • Nobody gives Javascript or C# answers on Java questions. Why do people post C++ answers to C questions? – Miles Rout Mar 06 '23 at 01:24
  • @MilesRout: Compare the wording of the text I quoted with the text from the original question. I was suggesting that the phraseology saying that the storage must be freed using free() or realloc() was intended to say that the storage "must be freed *using free() or realloc()*" as opposed to using some other method, as opposed to saying that the storage "*must be freed*" (as opposed to being left allocated until program termination). – supercat Mar 06 '23 at 02:19