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.
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.
-
-
To be valid it would have to meet them with all possible mallocs.
Thanks. Twitter will use this to make your timeline better. UndoUndo
-
-
-
You can reasonably argue that such a program is not portable or that it represents very bad engineering. But the programmer gets to use the freedom created by the compiler being conservative.
-
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.