4 ms·

Undefined behaviour being weird and having bizarre implications is not a feature of C. It is a feature introduced by compiler writers who prize esoteric optimi

Undefined behaviour being weird and having bizarre implications is not a feature of C. It is a feature introduced by compiler writers who prize esoteric optimisations more than simplicity. And it is not forbidden by the standard, though discouraged.

the_why_of_y 4y ago
Following your argument: Use-after-free or double-free is undefined behavior. 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.
- 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.
cycomanic 4y ago
> Undefined behaviour being weird and having bizarre implications is not a feature of C. How so? It is behavior left undefined in the C standard. > It is a feature introduced by compiler writers who prize esoteric optimisations more than simplicity. It's not the compiler writers who left the behaviour undefined, but the standard writers. If it was so clear what should be done (so all compiler writers should do it in one way) then why did they not define it? > And it is not forbidden by the standard, though discouraged. What do you mean it's not forbidden in the standard, it's undefined in the standard hence the name. Because of this you really should not rely on it, because the behavior could change.

the_why_of_y 4y ago

Following your argument: Use-after-free or double-free is undefined behavior. 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.

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.

cycomanic 4y ago

> Undefined behaviour being weird and having bizarre implications is not a feature of C. How so? It is behavior left undefined in the C standard. > It is a feature introduced by compiler writers who prize esoteric optimisations more than simplicity. It's not the compiler writers who left the behaviour undefined, but the standard writers. If it was so clear what should be done (so all compiler writers should do it in one way) then why did they not define it? > And it is not forbidden by the standard, though discouraged. What do you mean it's not forbidden in the standard, it's undefined in the standard hence the name. Because of this you really should not rely on it, because the behavior could change.