Hi Quincey

I think I'd believe you :)))

if debug build behaves exactly the same way as release build does

but debug build reports correctly about malloc failure, therefore it's possible 
(at runtime) to detect memory allocation failure

it's faulty optimization to blame
about inability to detect memory allocation failure, suppose you're right (but 
in that case it's not clear how debug build is able to detect an error)

then how g++ and Visual Studio 2013 can do that? (on the same x86_64 platform) 
If they can do that then sure clang can do that as well

standard is very clear (at least at the year 2016) that in case of the 
allocation failure malloc should return NULL

and operator new should throw std::bad_alloc exception

or if we use new (std::nothrow) it should return nullptr


there is nothing in both standards about inability to detect memory allocation 
and optimization of malloc (at least I didn't find it)

if you can point me to the right place in standard where optimization or
inability on some hardware to detect allocation failure is discussed I'd be 
very grateful

thanks


Dmitry Markman



On Jul 04, 2016, at 07:37 PM, Quincey Morris 
<quinceymor...@rivergatesoftware.com> wrote:

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

Reply via email to