> On Jun 9, 2015, at 6:54 AM, Dave <[email protected]> wrote: > > I was just about to post as I figured it out, the thing is that malloc should > never return NULL and I thought the analyzer knew that, I guess it’s safer to > test anyway.
It’s sort of a gray area. In a 64-bit Darwin process I think it’s extremely unlikely. And on iOS I think the OS will abort your process before it can allocate enough memory to completely fill up RAM. But the C standard says malloc can return NULL if it can’t allocate the block, and there are many ways that can happen: - Disk fills up and the OS runs out of swap space for virtual memory - There’s no VM swap (i.e. iOS) and all of RAM gets allocated - A 32-bit process’s address space fills up or fragments, regardless of whether the system has enough RAM available (32-bit apps only have about 2GB of space for heap allocations! I’ve run into situations where a 50MB allocation failed simply because of fragmentation.) - The requested size is bigger than the amount of free address space available (yes, this can happen in 64-bit if you pass a crazy huge size — usually this means you passed a negative size by mistake!) (Historical note: Malloc failures used to be a huge source of frustration to developers in the ‘classic’ Mac OS, because they were extremely likely to occur and it was very hard to test all possible failure cases, so they tended to cause bad behavior or crashes.) —Jens (apologies for any TMI) _______________________________________________ Cocoa-dev mailing list ([email protected]) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [email protected]
