[OT?] xmalloc

Discussion in 'C Programming' started by Jeff, Jul 1, 2003.

  1. Jeff

    Jeff Guest

    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
     
    Jeff, Jul 1, 2003
    #1
    1. Advertising

  2. Jeff <> wrote in
    news:pQiMa.7764$:

    > 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 ->
    --
     
    Mark A. Odell, Jul 1, 2003
    #2
    1. Advertising

  3. 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/
     
    Bertrand Mollinier Toublet, Jul 1, 2003
    #3
  4. Jeff

    Kevin Easton Guest

    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


    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.
     
    Kevin Easton, Jul 2, 2003
    #4
  5. Jeff

    Dan Pop Guest

    In <> Ben Pfaff <> writes:

    >Jeff <> 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, Jul 2, 2003
    #5
  6. Jeff

    Dan Pop Guest

    In <newscache$zkpdhh$kqk$> Kevin Easton <> writes:

    >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

    >
    >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, Jul 2, 2003
    #6
  7. Jeff

    Kevin Easton Guest

    Dan Pop <> wrote:
    > In <newscache$zkpdhh$kqk$> Kevin Easton <> writes:
    >
    >>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

    >>
    >>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.
     
    Kevin Easton, Jul 2, 2003
    #7
  8. Jeff

    Dan Pop Guest

    In <newscache$ulcehh$o5k$> Kevin Easton <> writes:

    >Dan Pop <> wrote:
    >> In <newscache$zkpdhh$kqk$> Kevin Easton <> writes:
    >>
    >>>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
    >>>
    >>>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, Jul 2, 2003
    #8
  9. Jeff

    Malcolm Guest

    "Jeff" <> 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.
     
    Malcolm, Jul 2, 2003
    #9
  10. Jeff

    Eric Sosman Guest

    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, Jul 7, 2003
    #10
  11. Jeff

    Dan Pop Guest

    In <> Eric Sosman <> writes:

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


    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
    --
    Dan Pop
    DESY Zeuthen, RZ group
    Email:
     
    Dan Pop, Jul 7, 2003
    #11
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Malcolm McLean

    xmalloc

    Malcolm McLean, Jun 23, 2007, in forum: C Programming
    Replies:
    52
    Views:
    1,812
    Ben Pfaff
    Jun 27, 2007
  2. Kelsey Bjarnason

    xmalloc string functions

    Kelsey Bjarnason, Jan 27, 2008, in forum: C Programming
    Replies:
    240
    Views:
    3,560
  3. xmalloc.c - my xmalloc

    , Feb 15, 2008, in forum: C Programming
    Replies:
    11
    Views:
    933
  4. Tim Hollingsworth

    Multi-threaded C++, new, and xmalloc

    Tim Hollingsworth, Nov 23, 2006, in forum: Ruby
    Replies:
    4
    Views:
    137
    Paul Brannan
    Nov 24, 2006
Loading...

Share This Page