bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: proper realloc(p,0) behavior?


From: Bruno Haible
Subject: Re: proper realloc(p,0) behavior?
Date: Fri, 25 Mar 2011 00:52:41 +0100
User-agent: KMail/1.9.9

Eric Blake asked:
> How should gnulib react?  And are there any existing GNU programs that
> would break ...?

There are three possible behaviours of realloc(p,0):
  (a) returns non-NULL pointer.
  (b) returns NULL and frees p.
  (c) fails and returns NULL.

Situation per platform:

   glibc   (b)
   FreeBSD (a), (c) if OOM
   OpenBSD (a), (c) if OOM
   AIX     (b)
   HP-UX   (b)
   IRIX    (a), (c) if OOM
   OSF/1   (b)
   Solaris (b)

So, code which calls realloc(p,0) and does not free p if that returns NULL
works OK on glibc, AIX, HP-UX, OSF/1, Solaris, but leaks memory in case of
out-of-memory on BSD, IRIX.

Whereas code which calls realloc(p,0) and frees p if that returns NULL
works OK on BSD, IRIX, but crashes on glibc platforms and leads to subtle
memory bugs on AIX, HP-UX, OSF/1, Solaris.

- Argue like this:

  There's no way to do it right. Therefore I think gnulib should encourage
  programmers to avoid calling realloc(p,0) at all.

  I propose to add a new module 'realloc-safe' which emits a diagnostic and
  then calls abort() if realloc(p,0) is called.

- Or argue like this:

  Leaking memory when you are already out of memory is not a problem: the
  program will need to terminate very soon anyway. So code which calls
  realloc(p,0) and does not free p if that returns NULL is just fine.

Which argumentation do you prefer?

Bruno
-- 
In memoriam Óscar Romero <http://en.wikipedia.org/wiki/Óscar_Romero>



reply via email to

[Prev in Thread] Current Thread [Next in Thread]