corinthia-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dennis E. Hamilton" <>
Subject RE: More on the xmalloc project
Date Fri, 27 Feb 2015 16:04:35 GMT
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 [] 
Sent: Friday, February 27, 2015 03:53
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 []
> Gesendet: Freitag, 27. Februar 2015 11:11
> An:
> Betreff: Re: More on the xmalloc project
> > On 27 Feb 2015, at 3:59 am, Gabriela Gibson
> <> 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
> PGP key: <
> key> (fingerprint 5435 6718 59F0 DD1F BFA0 5E46 2523 BAA1 44AE 2966)

View raw message