> Following your argument: It's not an argument, it's an observation and statement of fact. > Use-after-free or double-free is undefined behavior. Yes. > Th

> Following your argument: It's not an argument, it's an observation and statement of fact. > Use-after-free or double-free is undefined behavior. Yes. > Therefore Why therefore? > a C implementation that provides malloc(3) should provide an implementation of free(3) that is a no-op and provide a garbage collector that actually frees the memory. If you think so. It certainly doesn't follow from what I wrote. My point is that if you use a pointer after you freed the memory, you get whatever is in memory that the pointer points at on the machine the code is running on. That is not a "weird and bizarre" implication, it is a plain and straightforward implication given how C is implemented on real machines. It is (obviously, I hope!) outside of the scope of the C standard to say what will be at that memory location at that point, and therefore it is UB. And it being UB, "what you get" may also, for example, be a segfault because the library/OS have decided to unmap that memory. And again, that is also not "weird and bizarre", but perfectly straightforward. ¯\_(ツ)_/¯