[OT?] xmalloc
 

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

Re: [OT?] xmalloc
 

Jeff <jeff@whitehouse.gov> wrote in
news:PQiMa.7764$Fl5.5012@nwrddc02.gnilink.net:

> 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.

--
- Mark ->
--

Re: [OT?] xmalloc
 

Jeff wrote:
> 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 :-/

--
Bertrand Mollinier Toublet
Currently looking for employment in the San Francisco Bay Area
http://bmt-online.dapleasurelounge.com/

Re: [OT?] xmalloc
 

Jeff <jeff@whitehouse.gov> wrote:
> 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.

Re: [OT?] xmalloc
 

In <87znjyxjbx.fsf@pfaff.Stanford.EDU> Ben Pfaff <blp@cs.stanford.edu> writes:

>Jeff <jeff@whitehouse.gov> writes:
>
>> 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.
>
>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
DESY Zeuthen, RZ group
Email: Dan.Pop@ifh.de

Re: [OT?] xmalloc
 

In <newscache$zkpdhh$kqk$1@tomato.pcug.org.au> Kevin Easton <kevin@-nospam-pcug.org.au> writes:

>Jeff <jeff@whitehouse.gov> wrote:
>> 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.

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
--
Dan Pop
DESY Zeuthen, RZ group
Email: Dan.Pop@ifh.de

Re: [OT?] xmalloc
 

Dan Pop <Dan.Pop@cern.ch> wrote:
> In <newscache$zkpdhh$kqk$1@tomato.pcug.org.au> Kevin Easton <kevin@-nospam-pcug.org.au> writes:
>
>>Jeff <jeff@whitehouse.gov> wrote:
>>> 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.
>
> 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.

Re: [OT?] xmalloc
 

In <newscache$ulcehh$o5k$1@tomato.pcug.org.au> Kevin Easton <kevin@-nospam-pcug.org.au> writes:

>Dan Pop <Dan.Pop@cern.ch> wrote:
>> In <newscache$zkpdhh$kqk$1@tomato.pcug.org.au> Kevin Easton <kevin@-nospam-pcug.org.au> writes:
>>
>>>Jeff <jeff@whitehouse.gov> wrote:
>>>> 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.
>>
>> 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.

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
--
Dan Pop
DESY Zeuthen, RZ group
Email: Dan.Pop@ifh.de

Re: [OT?] xmalloc
 

"Jeff" <jeff@whitehouse.gov> wrote in message
> 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.

Re: [OT?] xmalloc
 

Kevin Easton wrote:
>
> 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.

--
Eric.Sosman@sun.com