Welcome to Software Development on Codidact!
Will you help us build our independent community of developers helping developers? We're small and trying to grow. We welcome questions about all aspects of software development, from design to code to QA and more. Got questions? Got answers? Got code you'd like someone to review? Please join us.
Comments on Is it UB to read value of heap pointer after freeing?
Parent
Is it UB to read value of heap pointer after freeing?
I've read in a guide that "the use of indeterminate memory for anything, including apparently harmless comparison or arithmetic, can have undefined behavior if the value can be a trap representation for the type."
The included quote from C11, section 6.2.4 §2, says:
The value of a pointer becomes indeterminate when the object it points to (or just past) reaches the end of its lifetime.
The reason I'm mentioning the quote here is partially because I don't have a copy of the C standard.
Is reading the value of a pointer returned by a heap allocation function after its deallocation truly an instance of undefined behavior? (For example, debuggers may read and output the address to various I/O destinations: printer, screen, disk, network, etc.)
Consider the following program:
#include <stdio.h>
#include <stdlib.h>
int main(void) {
void *pointer = malloc(1);
if (pointer == NULL) return 1;
free(pointer);
printf("%p\n", pointer); /* Reading the address. Undefined behavior? */
return 0;
}
Does the specification for this differ across ANSI C and other versions of ISO C?
Post
The following users marked this post as Works for me:
| User | Comment | Date |
|---|---|---|
| Intel A80486DX2-66 |
Thread: Works for me With the essential clarification provided by alx in their comment |
Aug 23, 2026 at 01:49 |
This is not a C issue, but really about dynamically allocated memory in general.
Think about it. When you allocate a chunk of dynamic memory, the heap manager finds an available memory region of the right size (or tells you it can't give you the requested memory), marks it as in-use, and returns you a pointer to it. When you release the chunk, the heap manager marks it as unused.
What happens to the memory after that is not your business. You have no guarantee that the memory hasn't been allocated by another thread, implicitly by the run-time library, or whether the address is even still valid in your address space. It could cause a memory fault if you try to read from it.
Is reading the address returned by a heap allocation function after its deallocation truly an instance of undefined behavior?
Yes! That's the point of deallocating memory. You are saying that you're done with it. That means something else is free to use it, and may have by the time you try dereferencing the pointer again. Depending on the OS, it may have been marked as invalid memory for you and trigger some kind of trap when you try to access it.
Again, think about it. How else do you expect it to work? If you still wanted to access the memory, then you wouldn't deallocate it yet. Once you do deallocate it, it's not yours anymore.
1 comment thread