xmalloc

[Malcolm McLean]

Continuing the error-handling thread.

I am floating

void *xmalloc(int sz)
{
void *answer;

assert(sz >= 0);
if(sz == 0)
sz = 1;
answer = malloc(sz);
if(!answer)
{
fprintf(stderr, "Can't allocate %d byte%c\n", sz, sz == 1 ? ' ', 's');
exit(EXIT_FAILURE);
}
return answer;
}

as a solution to the malloc() problem.
(Chuck Falconer's suggestion)
You call it for trivial allocations on the basis that if the computer won't
give a few bytes of memory, not much can be done.
However you wouldn't call it to allocate an image, for example, because
legitmate images can be quite large in relation to computer memories.
--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm

[Malcolm McLean]

"Christopher Benson-Manica" <at***@faeroes.freeshell.orgwrote in message
news:f5**********@chessie.cirr.com...

Harald van D?k <tr*****@gmail.comwrote:

>malloc(0) can make sense, but is allowed by the standard to either return
NULL or non-NULL on success. Because of this, xmalloc(0) calls malloc(1)
so
that a successfull allocation will always return non-NULL.

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.

There's quite a strong case for that.
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.

However with xmalloc() we never need the check, so the problem doesn't
arise.

--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm

[Ben Pfaff]

"Malcolm McLean" <re*******@btinternet.comwrites:

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.

Another peril of such code is the tendency to forget that width *
height can overflow. I used to ignore this possibility entirely;
these days, I generally use helper functions that carefully check
multiplications and additions for overflow.
--
Ben Pfaff
http://benpfaff.org