Re: xmalloc


"Richard Heathfield" <rjh@xxxxxxxxxxxxxxx> wrote in message news:kbednX2M0Nuh9-DbnZ2dnUVZ8qOtnZ2d@xxxxxxxxx
Malcolm McLean said:

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.

What malloc() problem? And this "solution" suffers from the same problem
as any other "solution" of the same kind - it's no earthly use in a
library, and libraries are where malloc calls belong.

There are two reasons why it's no earthly use in a library.

For one thing, it displays a message on stderr, which isn't much cop in
a system where stderr messages are ignored - e.g. a Win32 GUI app. But
that's trivial to fix - either remove the message completely, or add a
callback or a pointer to an error code, so that the application can
worry about how to display the message.

The second problem is also quite easy to fix, and it's this - the
function calls exit(), thus taking the decision to quit the program out
of the hands of the programmer. Therefore, the programmer won't call
this function himself, and won't be able to call any other function in
the library that /does/ call it.

Here's my suggested replacement, which incorporates all the fixes I see
as being necessary:

#include <stdlib.h>

void *xmalloc(size_t sz)
{
return malloc(sz);
}


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.

Whether that is true depends on the problem you're trying to solve. For
example, it may well be possible to switch to a static solution which
is perhaps not as fast as the dynamic solution but which will
nevertheless do the Right Thing in a reasonable time.

In which case would call regular malloc()
However you are doubling the cost of the software with that strategy, all because a 2GB machine might refuse to give a few hundred bytes of memory. If it is running a life-support machine, fair enough, but most software doesn't.

On the other hand you could argue that xmalloc() is a bad idea, because no library that uses it could ever find its way into a life-support machine.
On the other hand, you could argue that the life support machine is more likely to blow a fuse than to exit in xmalloc(), so you need a backup anyway.

I take your point about vandalised stderrs.
Maybe we should put an assert fail in there as well / instead.
--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm


.

Relevant Pages

  • Re: xmalloc
    ... void *xmalloc ... as a solution to the malloc() problem. ... and libraries are where malloc calls belong. ... Therefore, the programmer won't call ...
    (comp.lang.c)
  • Re: [LONG] Re: Why code completion and early error checking are needed
    ... >> the programmer who wants such features. ... > libraries to find the type declaration. ... If you type std::vector that means the one from the Standard. ... > of the language to have certain naming and declaration standards ...
    (comp.lang.cpp)
  • [LONG] Re: Why code completion and early error checking are needed
    ... > the programmer who wants such features. ... the guiding principles in the evolution of the c++ language should be ... the problem with this is that ide must first be able to assume ... libraries to find the type declaration. ...
    (comp.lang.cpp)
  • Re: Odd behaviur...
    ... libraries, most of which are your own, the includes are easily managed. ... >>left wondering why a programmer capable of producing such code would ... Delphi and inserted as dlls into the existing C code base. ... made to new looking apps with Delphi GUI and C dlls carrying the older code. ...
    (comp.lang.pascal.delphi.misc)
  • Re: Oft-shared (perhaps?) Impressions of a Lisp Newbie
    ... library" of Common Lisp? ... If something isn't in the language, it will be in some common library, ... you might find M linked list libraries and N ... The more years you spend as a programmer, the more you learn ways to ...
    (comp.lang.lisp)