thanks it’s very well possible that release/debug malloc have different implementation
but end code should behave exactly the same regardless of implementation if debug build reports that malloc failed and information about that is used elsewhere (as exit code) then release build must behave in the same way, it’s simple as that thanks again dm > On Jul 4, 2016, at 8:27 PM, Roland King <r...@rols.org> wrote: > > >> On 5 Jul 2016, at 08:02, Dmitry Markman <dmark...@mac.com >> <mailto:dmark...@mac.com>> 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. >> >> >> there is nothing in both standards about inability to detect memory >> allocation and optimization of malloc (at least I didn't find it) > No there isn’t anything about optimisation in the standards because all the > standard says it that malloc returns NULL on failure. If an implementation of > malloc is defined never to fail,it never returns NULL. If the compiler knows > that that implementation of malloc (builtin) never returns NULL in release > mode, and also knows about the malloc()/free() pairing, it can remove the > whole thing as dead code, because it is dead code, it cannot possibly be > executed because that implementation of malloc cannot possibly return NULL. > > 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. Dmitry Markman
_______________________________________________ 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
