Apple

On 5 Jul 2016, at 08:02, Dmitry Markman <email@hidden> wrote:

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

That’s an implementation detail. If I remember correctly somewhere in this long thread you or someone stated that turning builtins off changes the behaviour. As Quincey put in his first reply it’s quite possible that malloc in release mode doesn’t do the checks about physical memory, gives you a pointer and decides the virtual memory system will work it out later. This is generally good behaviour because it checks in debug mode when you’re testing and catches gross memory allocation errors, and rips through at top speed in release when you are performing.

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

And the release version of the built-in malloc is defined not to fail so it *never* returns NULL. It gives you a valid pointer and defers whether that memory request can be fulfilled to the time you use the pointer and if it can’t at that time after the VM system has swapped and thrashed and beachballed, then you crash.

So the compiler and optimiser are doing exactly the right thing given that malloc() in this instance will never return null. You can argue that having a malloc() which doesn’t even allow the possibility of returning NULL is a buggy malloc() implementation, but since the VM system is so complicated and it’s impossible to know how much of the memory will be in use at any given time, what else is running, what can be swapped out, then an optimistic malloc() is not unreasonable.

References:
	>Re: malloc was optimized out (From: Dmitry Markman <email@hidden>)