[prev in list] [next in list] [prev in thread] [next in thread]
List: busybox
Subject: Re: [BusyBox] bug in cut in 0.60.2
From: Stewart Brodie <stewart.brodie () pace ! co ! uk>
Date: 2002-02-26 9:36:04
[Download RAW message or body]
In message <20020226161642.GB365@lafn.org>
Matt Kraai <kraai@alumni.cmu.edu> wrote:
> On Tue, Feb 26, 2002 at 05:08:26PM +0100, Axel Kittenberger wrote:
> >
> > > I don't see this error. My libc must be returning a non-NULL
> > > value for zero-length allocations.
> >
> > void * xmalloc(size_t size) {
> > if (size == 0) {
> > size = 1;
> > }
> > return malloc(size) }
> >
> > This way you can be sure that you'll always get a non NULL pointer, with
> > the cost of an additional wasted byte per 0 allocation (beside the heap
> > frame).
>
> I don't see why we need to guarantee that the pointer we return isn't NULL.
> Would someone please enlighten me?
It doesn't need to be non-NULL - however, it can help less well written
library clients. You are permitted to return a NULL pointer or a pointer to
a zero byte (at least) block. Somebody's walked out with my copy of the C
standard, so I can't check, but if the behaviour is implementation-defined,
then whatever you choose you must place in a document. Is there a document
for uClibc describing all the implementation-defined decisions that refer to
a C library? I couldn't see one on a quick trawl through the CVS repository.
--
Stewart Brodie, Senior Software Engineer
Pace Micro Technology PLC
645 Newmarket Road
Cambridge, CB5 8PB, United Kingdom WWW: http://www.pacemicro.com/
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic