[BusyBox] bug in cut in 0.60.2

Stewart Brodie stewart.brodie at pace.co.uk
Tue Feb 26 09:36:04 UTC 2002


In message <20020226161642.GB365 at lafn.org>
          Matt Kraai <kraai at 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/



More information about the busybox mailing list