Hi Chris you’re right only in your last part that clang isn’t my problem
there were much better explanation what’s going on, you should learn from other people how to answer questions. there was magical word tradeoff, that you clearly missed. Theoretically clang isn’t right, because my initial code should behave identically for debug and release build and malloc *can* return NULL and therefore clang is inconsistent. but if we take into consideration all explanations that people gave here clang behavior is reasonable for all practical purposes every vendor can implement standard in the different level of accuracy. No one will kill vendor if its implementation isn’t 100% standard compliant as long as normal explanations were given (thanks Jens, Clark, Carl, Steve and others) I’m ok, so frankly you’re wrong that I don’t agree I do agree. in relation to clang, we reported many bug reports and some were fixed, so we don’t have to deal with clang all the time, sometimes clang has to deal with us :) the same is true for Apple, Microsoft, boost, ICU, sqlite and many other vendors, so please Chris don’t teach me how to deal with clang and when and how report bug reports otherwise thank you very much for your answer dm > On Jul 4, 2016, at 11:27 PM, Chris Cleeland <chris.cleeland+xc...@gmail.com> > wrote: > > Whether you agree or disagree with what clang does, it doesn't matter. clang > is doing what it is doing; *YOU* have to deal with it in your code. > > Your contrived example is not at all like the example you provided where the > pointers in a struct-returned-by-value are assigned to the return value of > malloc(). In the contrived example clang is well within its rights to > optimize out the call to malloc as has been explained well by others (yes, I > know you don't agree but that honestly doesn't matter because, frankly, > you're wrong in that regard). > > I think that if you want to report a bug, you need to model things after your > more complicated example because based solely on what you show it seems less > likely that the optimizer has enough information to optimize out a malloc. > > If you really want to know how much space is available for heap allocation, > you're going to have to try to touch every page in your requested set. Even > then there would be cases you can't accommodate such as when memory gets > freed up you wouldn't know about it. > > To really do this correctly, you are going to have to dive down and get > intimate with the VM subsystem of each OS on which you run, and hopefully > create an abstraction over it that permits you to do what you feel you need. > > But, at this point, based on the evidence, clang is not your problem. > > > On Mon, Jul 4, 2016 at 9:59 PM, Dmitry Markman <dmark...@mac.com > <mailto:dmark...@mac.com>> wrote: > yes I tried it was 0 > > > few people said here that malloc never returns NULL and therefore code like > ((data = malloc(sz)) == NULL) can be optimized out > > however I create very simple program where malloc does return NULL even in > release build > > so clang is at very least inconsistent > > > consider 2 cpp files and one header > > 1. memory_use.hpp > > struct S { > unsigned char *mem; > }; > > S *allocate_structure(size_t sz); > > void dellocate_structure(S *& s); > > > 2. memory_use.cpp > > #include "memory_use.hpp" > > #include <iostream> > > S* allocate_structure(size_t sz) { > S *s = (S *)malloc(sizeof(S)); > if((s->mem = (unsigned char *)malloc(sz)) == nullptr) { > std::cout << "allocate_structure mem allocation failure" << std::endl; > free(s); > return nullptr; > } > return s; > } > > void dellocate_structure(S *& s) { > if(s == nullptr) return; > free(s->mem); > free(s); > s = nullptr; > } > > > 3. main.cpp > > > int main(int argc, const char * argv[]) { > size_t need_size = 0x1000000000000; > // size_t need_size = 0x400000000000; > > std::cout << "need_size = " << need_size << std::endl; > > S *s = allocate_structure(need_size); > if(s == nullptr) { > std::cout << "allocation failure" << std::endl; > return 1; > } else { > if(s->mem) std::cout << "success" << std::endl; > dellocate_structure(s); > } > > return 0; > } > > > if I ask need_size = 0x1000000000000 (~250TB) > > I’m getting > > need_size = 281474976710656 > new_malloc_problem(35609,0x100080000) malloc: *** > mach_vm_map(size=281474976710656) failed (error code=3) > *** error: can't allocate region > *** set a breakpoint in malloc_error_break to debug > allocate_structure mem allocation failure > allocation failure > Program ended with exit code: 1 > > > if I ask need_size = 0x400000000000 (~60TB) > > I’m getting > > need_size = 70368744177664 > success > Program ended with exit code: 0 > > > so as you can see Jens was right and for 0x1000000000000 malloc did return > NULL > > in the code above optimization didn’t occurred and malloc did return NULL > > since > > 1. compiler hardly can predict runtime hardware behavior at the compile time > and > > 2. resulting code can run on different hardware configuration > > 3. code checks result of the malloc > > compiler shouldn’t optimize malloc out > > or runtime code should never return NULL for malloc. > > otherwise behavior is not consistent and unpredictable > > if malloc never returns NULL (except some edge cases as Jens explained) then > we have > > very bad situation, because we can’t reliably detect memory allocation failure > > before actual memory use :((( > > > thanks all > > dm > > > > > > > > > > > > > > > > > > On Jul 4, 2016, at 10:19 PM, Carl Hoefs <newsli...@autonomy.caltech.edu > > <mailto:newsli...@autonomy.caltech.edu>> wrote: > > > > RETURN VALUES > > If successful, calloc(), malloc(), realloc(), reallocf(), and valloc() > > functions return > > a pointer to allocated memory. If there is an error, they return a > > NULL pointer and set > > errno to ENOMEM. > > > >>> An implementation of malloc that never returns NULL is still compliant to > >>> the standard. > > > > Have you tried checking errno after the malloc? > > -Carl > > > > > > > >> On Jul 4, 2016, at 7:13 PM, Dmitry Markman <dmark...@mac.com > >> <mailto:dmark...@mac.com>> wrote: > >> > >> thanks > >> > >> unfortunately you started to play with words > >> > >> I asked for ~250TB of data from my MacBook Pro with 1TB SSD and 16GB of RAM > >> > >> clearly that amount can’t be given (in any circumstances) > >> > >> so if compiler returns something that isn’t NULL it’s very troubling > >> > >> thanks again > >> > >> dm > >> > >> > >> > >>> On Jul 4, 2016, at 9:20 PM, Clark Cox <clarkc...@gmail.com > >>> <mailto:clarkc...@gmail.com>> wrote: > >>> > >>> > >>>> On Jul 4, 2016, at 15:53, Dmitry Markman <dmark...@mac.com > >>>> <mailto:dmark...@mac.com>> 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 > >>> clarkc...@gmail.com <mailto:clarkc...@gmail.com> > >>> > >> > >> Dmitry Markman > >> > >> > >> _______________________________________________ > >> Do not post admin requests to the list. They will be ignored. > >> Xcode-users mailing list (Xcode-users@lists.apple.com > >> <mailto:Xcode-users@lists.apple.com>) > >> Help/Unsubscribe/Update your Subscription: > >> https://lists.apple.com/mailman/options/xcode-users/newslists%40autonomy.caltech.edu > >> > >> <https://lists.apple.com/mailman/options/xcode-users/newslists%40autonomy.caltech.edu> > >> > >> This email sent to newsli...@autonomy.caltech.edu > >> <mailto:newsli...@autonomy.caltech.edu> > > > > Dmitry Markman > > > _______________________________________________ > Do not post admin requests to the list. They will be ignored. > Xcode-users mailing list (Xcode-users@lists.apple.com > <mailto:Xcode-users@lists.apple.com>) > Help/Unsubscribe/Update your Subscription: > https://lists.apple.com/mailman/options/xcode-users/chris.cleeland%2Bxcode%40gmail.com > > <https://lists.apple.com/mailman/options/xcode-users/chris.cleeland%2Bxcode%40gmail.com> > > This email sent to chris.cleeland+xc...@gmail.com > <mailto:chris.cleeland%2bxc...@gmail.com> 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
