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.
-
-
Replying to @t2mykleb
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.
1 reply 0 retweets 0 likes -
Replying to @RichFelker
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."
1 reply 0 retweets 0 likes -
Replying to @t2mykleb
If it's under the user's control, user input changes the result of the function, => nonpure.
1 reply 0 retweets 0 likes -
Replying to @RichFelker
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. :)
1 reply 0 retweets 0 likes -
Replying to @t2mykleb
No, that's not my claim. Redefining the std functions is UB.
1 reply 0 retweets 0 likes -
Replying to @RichFelker
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.
1 reply 0 retweets 0 likes -
Replying to @t2mykleb @RichFelker
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.
1 reply 0 retweets 0 likes -
Replying to @t2mykleb @RichFelker
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.
1 reply 0 retweets 0 likes -
Replying to @t2mykleb
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.
2 replies 0 retweets 0 likes
To be valid it would have to meet them with all possible mallocs.
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.