Evil proposed compiler optimization: in __attribute(__pure__)__ functions, optimize malloc(n) to 0.
In particular on any implementation where the invoking user can control resource limits, it's always possible for any particular call to malloc to fail.
-
-
That isn't true and you know it isn't true. Classic linked list malloc that never returns memory to the OS will always succeed if you just freed a block of the size you're trying to allocate.
-
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.
- 3 more replies
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.