Correct malloc(0) is defined in the specification. What is, however, implementation defined is what is returned: a null pointer or a pointer with which one should not try to access its objects (since it is allocated with 0 bytes it can only be assumed that it is only the empty set). The implementation decision of null versus pointer with 0 bytes allocated is driven by factors beyond the scope of our concerns--- but there are some very specific use cases where it could be useful (think realloc where it does not need to move the block). NOTE: malloc(0) when it does not return a NULL can consume memory and needs to be freed-- since free(NULL) is OK we can readily free any pointer result of a malloc without worries.
> -----Ursprüngliche Nachricht----- > Von: Peter Kelly [mailto:[email protected]] > Gesendet: Freitag, 27. Februar 2015 11:11 > An: [email protected] > Betreff: Re: More on the xmalloc project > > > On 27 Feb 2015, at 3:59 am, Gabriela Gibson > <[email protected]> wrote: > > > > Hi Peter, (and everyone else!) > > > > I read your JIRA comment, and that's an interesting thing with the > > missing headerfiles. My build report[1] was OK so, maybe different > > compilers take headers in a different order? > > > > Regards the clang build, should/could we have this as a regular build > > option in the CMake file? > > I don’t really have an opinion on this personally… it’s the default > compiler on OS X. Depends if people want to use clang on linux/windows > as well. > > I wouldn’t regard it as a priority right now. > > > Another thing to notice was that my test had quite a lot of malloc 0 > > calls, so whatever is run there, maybe it could do with a check, or > > perhaps xmalloc should check for if (!size) … ? > > It’s valid to call malloc with a request of 0 bytes. > > — > Dr Peter M. Kelly > [email protected] > > PGP key: http://www.kellypmk.net/pgp-key <http://www.kellypmk.net/pgp- > key> (fingerprint 5435 6718 59F0 DD1F BFA0 5E46 2523 BAA1 44AE 2966)
