[OT?] xmalloc

[Jeff]

I'm not sure if this is off-topic, it's not so much an ANSI-C question
as it is a group etiquette question. Like many people I wrap my *allocs
with error handling. I use the GNU x*alloc convention. But when I post
snippets I lop off the x which leaves me with an ANSI-C function but no
error handling. As a result, I receive responses which admonish me to
handle *alloc-ing errors.

My question: Should I?
a. leave the x*alloc function and state that it handles errors
b. lop off the x and listen to people tell me I'm a fool
c. lop off the x and add error handling to the snippet
d. never allocate memory again

 

[Mark A. Odell]

My question: Should I?
a. leave the x*alloc function and state that it handles errors
b. lop off the x and listen to people tell me I'm a fool
c. lop off the x and add error handling to the snippet
d. never allocate memory again

d. just use registers. Seriously, I'd say a.

 

[Bertrand Mollinier Toublet]

I'm not sure if this is off-topic, it's not so much an ANSI-C question
as it is a group etiquette question. Like many people I wrap my *allocs
with error handling. I use the GNU x*alloc convention. But when I post
snippets I lop off the x which leaves me with an ANSI-C function but no
error handling. As a result, I receive responses which admonish me to
handle *alloc-ing errors.

My question: Should I?
a. leave the x*alloc function and state that it handles errors
b. lop off the x and listen to people tell me I'm a fool
c. lop off the x and add error handling to the snippet
d. never allocate memory again

Go for option d. ;-)

More seriously, it seems, from your description that your x*alloc
functions do *not* have the same semantics as the *alloc functions.
Maybe you want to review that design. While the *alloc functions can
always fail (when the system has no more memory to alloc, it has no more
memory to alloc...), the x*alloc functions should strive at controlling
programming errors, such as not freeing alloc'ed memory, freeing it more
than once, using freed memory, writing out of bounds of alloc'ed memory.
You can add all those functionalities without changing the basic
semantics of the *alloc functions (that is returns a pointer to the
alloc'ed memory in case of success, and NULL else), so that your code
will still handle the case where (x)*alloc returns NULL and when posting
to Usenet, you can safely remove the x and not be called a fool.

Anyway, my 2 cents :-D I am basically telling you to rewrite your
x*alloc functions from scratch :-/

 

[Kevin Easton]

I'm not sure if this is off-topic, it's not so much an ANSI-C question
as it is a group etiquette question. Like many people I wrap my *allocs
with error handling. I use the GNU x*alloc convention. But when I post
snippets I lop off the x which leaves me with an ANSI-C function but no
error handling. As a result, I receive responses which admonish me to
handle *alloc-ing errors.

My question: Should I?
a. leave the x*alloc function and state that it handles errors

If the x*alloc function isn't too long, do this and include the code for
it as part of the post. If the code is too long, write a minimal
version with the same semantics.

- Kevin.

 

[Dan Pop]

I recommend using plain malloc() and stating in your commentary
that error handling is left out for simplicity.

I agree that this is the most efficient way of shutting up this kind
of remarks.

Dan

 

[Dan Pop]

If the x*alloc function isn't too long, do this and include the code for
it as part of the post. If the code is too long, write a minimal
version with the same semantics.

What's wrong with simply stating that it's a wrapper that handles errors,
as long as this is irrelevant to what the code is supposed to illustrate?

Dan

 

[Kevin Easton]

What's wrong with simply stating that it's a wrapper that handles errors,
as long as this is irrelevant to what the code is supposed to illustrate?

Nothing, but

void *xmalloc(size_t size) {
void *p = malloc(size);
if (!p) exit(EXIT_FAILURE);
return p;
}

isn't much more effort to type (or more likely, cut-and-paste), and leaves
no room for ambiguity. But stating the same thing in english rather
than C is probably just as good in most cases.

- Kevin.

 

[Dan Pop]

Nothing, but

void *xmalloc(size_t size) {
void *p = malloc(size);
if (!p) exit(EXIT_FAILURE);
return p;
}

isn't much more effort to type (or more likely, cut-and-paste), and leaves
no room for ambiguity.

It leaves enough room to the idiot pedant to point out that calling exit()
from a wrapper is not a good thing. Seen it before...

But stating the same thing in english rather
than C is probably just as good in most cases.

Stating in English that the wrapper takes care of error handling *without*
specifying how has a better chance of keeping the idiot pedant quiet

Dan

 

[Malcolm]

I'm not sure if this is off-topic, it's not so much an ANSI-C question
as it is a group etiquette question. Like many people I wrap my *allocs
with error handling. I use the GNU x*alloc convention. But when I post
snippets I lop off the x which leaves me with an ANSI-C function but no
error handling. As a result, I receive responses which admonish me to
handle *alloc-ing errors.

My question: Should I?
a. leave the x*alloc function and state that it handles errors
b. lop off the x and listen to people tell me I'm a fool
c. lop off the x and add error handling to the snippet
d. never allocate memory again

d. If you imagine that it is possible to write a wrapper that does error
handling acceptably then you shouldn't be using dynamic memory.

Seriously, all a wrapper can do is terminate the program with an error
message. On many platforms you can't even output the message easily.
Generally the correct solution to an out-of-memory condition is to return
some sort of error code to a higher-level function. Probably that function
will respond by terminating the program, but at least it will have a chance
to do some intelligent cleanup, promt for a save, etc.

It is possible to define an atexit() function that does these things, but I
have never seen this done in real code.

 

[Eric Sosman]

void *xmalloc(size_t size) {
void *p = malloc(size);
if (!p) exit(EXIT_FAILURE);
return p;
}

An suggestion: write the test as

if (p == NULL && size > 0)

or equivalent, to guard against the possibility that
the local implementation of malloc(0) might return NULL.
A NULL return in this case really shouldn't be considered
an "allocation failure," and shouldn't halt the program.

 

[Dan Pop]

An suggestion: write the test as

if (p == NULL && size > 0)

or equivalent, to guard against the possibility that
the local implementation of malloc(0) might return NULL.
A NULL return in this case really shouldn't be considered
an "allocation failure," and shouldn't halt the program.

It entirely depends on the program. If no *correct* xmalloc call can
request the allocation of zero bytes, the wrapper should be written like
this instead:

void *xmalloc(size_t size)
{
void *p = malloc(size);
assert(size > 0);
if (!p) exit(EXIT_FAILURE);
return p;
}

I consider code deliberately trying to allocate zero bytes as broken by
design.

Dan