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."
"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.