I don't understand the thinking here. Let's step back a little bit.
The reason for our introduction of an xmalloc() is to prevent return of NULL until there is a better approach to dealing with resource exhaustion based on the context and what the application is able to provide other than abrupt termination. If the input parameter is 0 and the malloc() behavior is to return either NULL or a non-NULL but not-usable address, it would seem appropriate to not allows such cases in *our* xmalloc(), especially because of the potential need to free something (although free tends to quietly figure out when it need not actually do anything). In this case, for the cases that apply to us, xmalloc() should treat an input of 0 as if malloc() returned NULL, but without calling malloc(), since presumably our code should never do that. (Using a debug assert might be better because of that, although my own preference is to not have debug builds provide different behavior than production builds.) Additional question: Is xmalloc() already a well-defined provision of some platform libraries? Then perhaps it is necessary to adopt a name that will not be confused with one of those? - Dennis -----Original Message----- From: Edward Zimmermann [mailto:[email protected]] Sent: Friday, February 27, 2015 03:53 To: [email protected] Subject: AW: More on the xmalloc project 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)
