Re: When to check the return value of malloc

Ian Collins said:

CBFalconer wrote:
Eric Sosman wrote:
2) The test should be `if (!res && s)'.

That is more easily handled by:

void *xmalloc(size_t s) {
void *res;

if (!s) s++;

Why?

I'll take a stab at that. But before I do, I'll just say that I'd prefer to
express it as:

if(s == 0)
{
s = 1;
}

but then I always did call a spade a manually operated agricultural
excavation implement. :-)

Now, I *think* the problem Chuck is trying to address is this: if you
allocate a zero amount of memory (and *why*, precisely, would anyone want
to do this?), the Standard has this to say: "If the size of the space
requested is zero, the behavior is implementation-defined; the value
returned shall be either a null pointer or a unique pointer."

So either you get NULL or you get a pointer you can't use, and you don't
know which will happen unless you consult the implementation's
documentation (which might not even be available - one of the benefits of
sticking to portable C is that we can write code and send it off to some
other party, who may well be using an implementation we've never heard of,
let alone have documentation for). I can easily see why it might be
convenient to "normalise" the behaviour by changing the allocation request
to one where malloc must return a valid and usable pointer if it succeeds.

It gets worse. On at least one implementation that I've used myself,
malloc(0) crashes (or "abends", since it was a mainframe implementation)
the process. That isn't one of the behaviours that the Standard allows,
but this *is* the real world, right? We can't allow for every possible bug
in every possible implementation, but we can at least take care of some of
the ones we *do* know about. So what is the Right Thing here? We could
simply reject the request completely, or we could allocate space for one
byte rather than zero bytes, simply to avoid a crash. Either strategy is
defensible. Personally, I think I'd prefer to reject the request, but
allocating one byte instead is a perfectly sensible workaround.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
.

Relevant Pages

  • Re: two dimensional arrays:
    ... you can create a 2 dimensional array via following ... >> Since your two allocate functions use the same allocation logic, ... both allocation pointers are of type void pointer. ...
    (comp.lang.c)
  • Re: size_t or int for malloc-type functions?
    ... I have not worked with 16-bit machines ... want to allocate>32K to a single object. ... void *smalloc{ ... conversion to size_t turns this into a request ...
    (comp.lang.c)
  • Re: BeginInvoke on a delegate
    ... and that author provides a more complete implementation of your managed wrapper class. ... This wrapper didn't allocate that memory. ... Those are the semantics of the class -- passing it a pointer means it'll take ownership of the allocated memory. ... void MyOtherSub{ ...
    (microsoft.public.dotnet.languages.vc)
  • Re: When to check the return value of malloc
    ... void *xmalloc{ ... allocate a zero amount of memory (and *why*, precisely, would anyone want ... returned shall be either a null pointer or a unique pointer." ... My preference would be to make the action taken on a zero byte request a ...
    (comp.lang.c)
  • Re: Filling data in function...
    ... What is the best way to do pointer arithmetic, ... a chunk of memory for an array of data. ... > But how did you allocate the space for the character strings? ...
    (alt.comp.lang.learn.c-cpp)