3 ms·

Following your argument: Use-after-free or double-free is undefined behavior. Therefore a C implementation that provides malloc(3) should provide an implement

• mpweiher 4y ago
  > 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. ¯\_(ツ)_/¯
• scotty79 4y ago
  > Use-after-free or double-free is undefined behavior. It's an error even if it's undetectable by the compiler. I understand that nomenclature from few decades ago makes a distinction but nowadays we just call such thing an error.