Evil proposed compiler optimization: in __attribute(__pure__)__ functions, optimize malloc(n) to 0.
The nature of the malloc implementation isn't under the application's control. On an implementation with shared libs it can change just by upgrade. Failure is always potentially-reachable.
-
-
It's under the user's control. In particular, it's not under the compiler's control at the time it's making decisions about how to mess with the programmer's __attr__((const)) function. I think the only avenue of argument here is that malloc/free have a forbidden "effect."
-
If it's under the user's control, user input changes the result of the function, => nonpure.
-
That ship already sailed. nexttoward() is __attr__((const)) in my headers yet it's exposed as a weak symbol => can be overriden by user via LD_PRELOAD and similar => nonpure, according to you. :)
-
No, that's not my claim. Redefining the std functions is UB.
-
I'm not certain whether LD_PRELOAD (or dynamic linking in general) constitute "redefining" standard library functions according to the C standard, but that seems like another ship that has sailed in practice.
-
Ultimately, the compiler needs to make conservative assumptions about malloc() and nexttoward(). Given that C compilers today are decoupled from standard libraries, the only properties the compiler can make use of are those guaranteed by the standard.
-
In particular, the existence of a malloc impl where malloc never returns 0 when running a given program implies that the compiler cannot assume that a given "malloc fails" branch is reachable.
-
I think we just have different views here thst can't be reconciled. To me a program that depends on behavior of a particular malloc impl to satisfy invariants is simply not valid.
- 1 more reply
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.