Hi Quincey
thanks for the answer
it’s not clear what kind of pointer was returned by the program, because
code was build with optimization, so I wasn’t able to stop there in debugger
in any attempt to do something like
size_t m = (size_t)data;
and print m out clang started to behave as expected and didn’t optimize malloc
also the following code
unsigned char *data = (unsigned char *)malloc(need_size);
if(data[0x10000] == 0) {
printf("data == NULL\n");
return 1;
} else {
printf("data != NULL\n");
}
behaves incorrectly, it should SEGV, but malloc again was optimized out and I
got the same result:
data != NULL
Program ended with exit code: 0
another observation
the following code
unsigned char *data = (unsigned char *)malloc(need_size);
if(data == NULL) {
printf("data == NULL\n");
return 1;
} else {
printf("data != NULL <<<%d>>>\n", (int)data[0x100000]);
}
free(data);
didn’t SEGV and returns
data != NULL <<<0>>>
Program ended with exit code: 0
and that is clearly wrong and obviously I’m using result of the malloc call
here.
> On Jul 4, 2016, at 2:55 PM, Quincey Morris
> <quinceymor...@rivergatesoftware.com> wrote:
>
> On Jul 4, 2016, at 11:09 , Dmitry Markman <dmark...@mac.com> wrote:
>>
>> The compiler "knows" how malloc works, and is allowed to optimize as if it
>> never fails.
>
> I don’t know the answer, but it seems to me at least possible that it didn’t
> fail. It’s at least possible that it gave you an unmapped virtual allocation
> of the size you asked for.
>
> Under that theory, the reason for different behavior in a release build would
> be that it chooses to omit availability checking, perhaps because determining
> the amount of “real” memory is subtle and would be an unacceptable overhead.
> You could find out for sure by looking at the Darwin source code, I suppose.
>
> Incidentally, what pointer does it return in the release build? Does it look
> like a valid pointer? Can it be used as a valid pointer (e.g. for setting
> byte 0 of the block to something)?
>
> Also, the 48 bits of memory address space your block consumes is possibly
> within the range of what address space is normally available to apps. What
> happens if you request a much larger amount (e.g. 2 * 64 - 1)?
>
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
