understood thanks Clark
> On Jul 4, 2016, at 11:03 PM, Clark Cox <[email protected]> wrote: > > >> On Jul 4, 2016, at 19:13, Dmitry Markman <[email protected]> wrote: >> >> thanks >> >> unfortunately you started to play with words > > Interpreting the standard, and what a compiler is and isn’t allowed to do, > often comes down to “playing with words”. > >> I asked for ~250TB of data from my MacBook Pro with 1TB SSD and 16GB of RAM > > You could very easily ask for an insane amount of data, then touch the first > and last pages of it and only ever end up using 8K of physical memory. On a > similar machine (I.e. MBP, 16GB/1TB): > > % cat test.c > #include <stdio.h> > #include <stdlib.h> > #include <string.h> > > int main() > { > const size_t size = 1024LL * 1024 * 1024 * 1024; > char *buffer = malloc(size); > > strcpy(buffer, "String in first page"); > strcpy(buffer + (size - 20), "String in last page"); > > printf("First page: %p: %s\n", buffer, buffer); > printf("Last page: %p: %s\n", buffer + (size - 20), buffer + (size - > 20)); > > return 0; > } > % cc test.c && ./a.out > First page: 0x113aa2000: String in first page > Last page: 0x10113aa1fec: String in last page > > Not only did malloc not return NULL, I was able to write to and read from the > buffer, and as you see from the output, the addresses are indeed nearly a > terabyte apart. > >> clearly that amount can’t be given (in any circumstances) >> >> so if compiler returns something that isn’t NULL it’s very troubling > > I’m not discounting that. It *can* lead to non-intuitive behavior, but OS > writers have made that tradeoff, and in the general case (I.e. When nobody is > making such huge allocations) it pays off in terms of efficiency. > > Again, I’m not disregarding how this behavior has affected you, only > explaining it. > >> thanks again >> >> dm >> >> >> >>> On Jul 4, 2016, at 9:20 PM, Clark Cox <[email protected]> wrote: >>> >>> >>>> On Jul 4, 2016, at 15:53, Dmitry Markman <[email protected]> wrote: >>>> >>>> Hmm >>>> >>>> behavior you described is good receipt to un-robust software >>>> >>>> IMHO, all talks about “effective", “typically" and so on and on is matter >>>> of interpretation >>>> >>>> and are much less important than standard >>> >>> An implementation of malloc that never returns NULL is still compliant to >>> the standard. >>> >>>> first of all there is a standard and nothing more. In some cases standard >>>> says that behavior is undefined >>>> >>>> but in case of “malloc" and "operator new” everything is well defined >>> >>> The standard says that malloc returns NULL in case of failure. It however, >>> says nothing about what constitutes a failure, or *any* situations in which >>> NULL must be returned.. >>> >>> >>> >>> -- >>> Clark Smith Cox III >>> [email protected] >>> >> >> Dmitry Markman >> > Dmitry Markman _______________________________________________ Do not post admin requests to the list. They will be ignored. Xcode-users mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/xcode-users/archive%40mail-archive.com This email sent to [email protected]
