[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gnulib-bug
Subject:    Re: Bug Report: sed-4.1.4 misinterprets uClibc's malloc (patch
From:       Paul Eggert <eggert () CS ! UCLA ! EDU>
Date:       2005-08-26 20:33:45
Message-ID: 871x4gbfpy.fsf () penguin ! cs ! ucla ! edu
[Download RAW message or body]

Chuck Swiger <chuck@pkix.net> writes:

> In general, code which assumes that malloc() will never
> return NULL is missing a basic sanity check and will result in bugs.

Yes, and that's why gnulib has a malloc wrapper that addresses this
issue systematically.  The wrapper handles this sanity check, on
non-GNU hosts where it is needed.  The one-line change I installed yesterday
<http://lists.gnu.org/archive/html/bug-gnulib/2005-08/msg00205.html>
means that gnulib-using code will use the wrapper as needed.  This
addresses the problem in question.

> Check every call to malloc or realloc to see if it returned zero.

Code should continue to do that, of course.  But that's a different
matter.  The question is whether code also needs to check for
size-zero allocations.

The glibc folks have decided not to bother with checking against
size-zero allocations, as they can safely assume that a NULL return
from malloc means memory is exhausted, and this assumption simplifies
and speeds up the glibc code.  I would rather not change this.

To address the problem when using glibc code outside glibc, we can
either put in a lot of ifdefs, or we can leave the glibc code alone
and use a wrapper.  The latter is far simpler to maintain.

> The existence of GNU libc should not encourage people to write
> non-portable GNU software.

The software continues to be portable, after the above change is used.

> "In particular, don't unconditionally declare malloc or realloc.

The wrapper doesn't declare malloc or realloc unconditionally, so
we're OK on that ground too.

> GNU diff has an example in xmalloc.c.

Yes, and that's basically what the gnulib xalloc module does.

It all fits together (albeit perhaps not in the way you'd like :-).



[prev in list] [next in list] [prev in thread] [next in thread]