Re: malloc was optimized out
Re: malloc was optimized out
- Subject: Re: malloc was optimized out
- From: Dmitry Markman <email@hidden>
- Date: Tue, 05 Jul 2016 00:02:54 +0000 (GMT)
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 <email@hidden> wrote:
On Jul 4, 2016, at 15:53 , Dmitry Markman <
email@hidden> 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 (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden