Evil proposed compiler optimization: in __attribute(__pure__)__ functions, optimize malloc(n) to 0.
I think you misread. The point was that under extreme conditions the implementations is forced to make malloc fail, but it's never forced to make it succeed. Failure is always an option.
-
-
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.
- 4 more replies
New conversation -
-
-
But I don't have to run the program under extreme conditions.
Thanks. Twitter will use this to make your timeline better. UndoUndo
-
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.