Re: Bug Report: sed-4.1.4 misinterprets uClibc's malloc (patch included)

[Chuck Swiger]

Yuri Vasilevski wrote:
> On Thu, 25 Aug 2005 12:49:37 -0700
> Paul Eggert <address@hidden> wrote:
> > Yuri Vasilevski <address@hidden> writes:
> > > Recent versions of sed expect glibc behavior [from] malloc, i.e.
> > > malloc(0) return live pointer.  This is not true for uClibc (and many
> > > other old/classical libc implementations).
> >
> > Thanks, but I'd rather not go through the glibc regex implementation
> > looking for other instances of this problem; it will be a maintenance
> > and reliability hassle.
>
> Personally I think that it may be safer to code in terms of standard
> malloc as it's behavior is much more widely implemented and in my
> opinion saner, but I understand all the trouble it'll be to check
> each malloc regex code.
>
> Also glibc's realloc return NULL if size == 0, so in the places where
> realloc is used in regex the case of NULL pointers most be taken care
> off in any way.

Agreed.  In general, code which assumes that malloc() will never return NULL is 
missing a basic sanity check and will result in bugs.  Code which assumes that 
malloc(0) will return a live pointer to a minimal allocation rather than NULL 
works on some platforms but is non-portable.

Rather than rely on our opinion, let's see what the GNU Coding Standards at

http://www.gnu.org/prep/standards/standards.html#Compatibility

...has to say:

"4.1 Writing Robust Programs
[ ... ]
Check every call to malloc or realloc to see if it returned zero. Check realloc 
even if you are making the block smaller; in a system that rounds block sizes 
to a power of 2, realloc may get a different block if you ask for less space.

In Unix, realloc can destroy the storage block if it returns zero. GNU realloc 
does not have this bug: if it fails, the original block is unchanged. Feel free 
to assume the bug is fixed. If you wish to run your program on Unix, and wish 
to avoid lossage in this case, you can use the GNU malloc."

> > Instead, let's substitute a malloc that behaves compatibly with GNU
> > malloc.

The existence of GNU libc should not encourage people to write non-portable GNU 
software.  Later on, in Section 5.7 of the GNU Coding Standards, there is also:

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

Most GNU programs use those functions just once, in functions conventionally 
named xmalloc and xrealloc. These functions call malloc and realloc, 
respectively, and check the results.

Because xmalloc and xrealloc are defined in your program, you can declare them 
in other files without any risk of type conflict."

GNU diff has an example in xmalloc.c.

--
-Chuck