R
Roland Pibinger
Also what does the x mean in xmalloc? Iv'e seen it numerous of
times in sources.
eXtended malloc?
Also what does the x mean in xmalloc? Iv'e seen it numerous of
times in sources.
Also what does the x mean in xmalloc? Iv'e seen it numerous of
times in sources.
Eric Sosman said:Keith Thompson wrote On 06/26/07 00:05,:
malloc() is permitted to call exit()? When did
that happen?
The behavior of xmalloc is still *consistent* with the allowed
behavior of malloc; no portable code can assume that malloc(0) can
return a non-null result.
Eric said:Keith Thompson wrote On 06/26/07 00:05,:
.... snip ...
malloc() is permitted to call exit()? When did that happen?
pete said:This portable code:
http://www.mindspring.com/~pfilandr/C/get_line/get_line.c
has a malloc(0) call,
and does assume that a non-null result may be returned.
pete said:This portable code:
http://www.mindspring.com/~pfilandr/C/get_line/get_line.c
has a malloc(0) call,
and does assume that a non-null result may be returned.
CBFalconer said:Then that code is not portable.
Keith Thompson said:The behavior of xmalloc is still *consistent* with the allowed
behavior of malloc; no portable code can assume that malloc(0) can
return a non-null result.
Harald van D?k said:It depends on the project. Sometimes it matters to have different calls
to malloc(0) return values that do not compare equal, sometimes it
doesn't.
The fact that xmalloc differs from malloc is made clear enough by the
fact that it has a different name.
Keith said:CBFalconer said:Then that code is not portable.
Not at all. It assumes that a non-null result *may* be returned; more
precisely, it allows for that possibility.
Here's the relevant snippet (the INITIAL_BUFFER_SIZE macro expands to 0):
[...]
size = INITIAL_BUFFER_SIZE;
buff = malloc(size);
if (buff == NULL && size != 0) {
[...]
It only assumes failure if malloc returns NULL with a non-zero
argument. If malloc(0) returns NULL, it can't know whether it
succeeded or failed; I assume (without having studied the code) that
it doesn't care.
I accidentally created an infinite loop making a small allocations withCBFalconer said:He must be using Microsoft compilers
There's quite a strong case for that.Christopher Benson-Manica said:I take about half of this point. While the code as written did indeed
need to distinguish between failure to allocate non-zero bytes, and
successful allocation of zero bytes (a fact which I missed), it's not
clear to me that xmalloc()'s clients gain anything by essentially
having all calls to malloc(0) replaced by malloc(1). The pointer
returned by malloc(0), if not NULL, can't be used to access an object
anyway, so from xmalloc()'s clients' perspectives, it doesn't much
matter whether xmalloc(0) returns NULL or not:
void *xmalloc( size_t sz ) {
if( sz == 0 ) {
return NULL;
}
/* ... */
}
May as well save the call to malloc(0), if you ask me.
Malcolm McLean said:With standard malloc() the rule is an easy way of introducing a bug,
as you write
char *buff = malloc(width * height);
if(!buff)
{
/* failure code */
}
however maybe you want to be able to handle zero-dimensioned tables in
normal flow control.
Want to reply to this thread or ask your own question?
You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.