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.
My view is that the implementation has freedom to change internals at any time as long as it did not _document_ their consequences as contracts.
-
-
"malloc always succeeds here because a previously freed chunk gets reused" is an implementation detail that need not be stable and that's not knowable from a black box perspective.
-
But in practice we've broken "the implementation" into a compiler and a standard library, and we permit the user to swap out standard library implementations. Impl details are knowable to the user, but not to the compiler.
-
If the compiler uses assumptions about the stdlib that go beyond what's guaranteed by the standard, then by definition it's generating code that's wrong for some stdlib impl.
-
Again I understand what you're saying and I disagree. The application cannot depend on stdlib properties that are neither contractual or testable in order to satisfy its promises to the compiler.
-
The specific __attr__((const)) discussion we had is clouded by the attribute's ambiguous natural-language specification. If you're granting that, then we have a genuine disagreement. Sadly, it is late and I need sleep too much to engage further.
End of conversation
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.