[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Bug Report: sed-4.1.4 misinterprets uClibc's malloc (patch included)
From: |
Paul Eggert |
Subject: |
Re: Bug Report: sed-4.1.4 misinterprets uClibc's malloc (patch included) |
Date: |
Fri, 26 Aug 2005 13:33:45 -0700 |
User-agent: |
Gnus/5.1007 (Gnus v5.10.7) Emacs/21.4 (gnu/linux) |
Chuck Swiger <address@hidden> 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 :-).