On Jul 4, 2016, at 15:53 , Dmitry Markman <dmark...@mac.com> wrote:
>
> in case of “malloc" and "operator new” everything is well defined
What you’re failing to take into account, I think, is that the behavior is
well-defined like this (not in these words, perhaps):
If malloc fails to allocate the requested amount of memory, it returns
NULL and an error code.
That’s only well-defined in terms of how an error is *reported*. The
*circumstances* in which it will fail are platform-dependent, and hard to
predict. In particular, an allocation for X bytes can only fail if the
allocator is able to determine if X bytes actually available, and this is *not*
a well-defined concept on macOS. The allocator knows how much of this app’s
virtual address space is available, but memory is allocated and shared on a
multi-level basis in macOS. An app wanting to use memory may take away from the
memory available to other apps. This isn’t, after all, Windows in 1990, or
(worse) Mac OS in 1990.
I think the only way the allocator will know if the requested memory is
available to this app is to try writing to it. I dunno what the C language
experts think, but this suggests to me that you could try using calloc instead
for exactly that reason. It’d be a lot slower for large memory blocks, but if
it returns nil on failure to write then that should be what you want to know.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (Xcode-users@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/xcode-users/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
