[U-Boot] [PATCH] Prevent malloc with size 0

Graeme Russ graeme.russ at gmail.com
Mon Apr 2 00:40:05 CEST 2012


Hi All

Here we go again ;)

On Mon, Apr 2, 2012 at 12:21 AM, Marek Vasut <marek.vasut at gmail.com> wrote:
> Dear Joakim Tjernlund,
>
>> Marek Vasut <marek.vasut at gmail.com> wrote on 2012/04/01 16:01:56:
>> > Dear Joakim Tjernlund,
>> >
>> > > > Dear Mike Frysinger,
>> > > >
>> > > > > On Thursday, October 21, 2010 17:10:31 Graeme Russ wrote:
>> > > > > > On 22/10/10 06:51, Mike Frysinger wrote:
>> > > > > > > have u-boot return an error.
>> > > > > >
>> > > > > > Is NULL what you consider to be an error
>> > > > >
>> > > > > yes
>> > > > >
>> > > > > > Besides, is not free(NULL) valid (does nothing) as well?
>> > > > >
>> > > > > yes, free(NULL) should work fine per POSIX
>> > > > > -mike
>> > > >
>> > > > Well then, this patch wasn't accepted yet and I consider it OK to
>> > > > apply. Any objections?
>> > >
>> > > There was a long debate on the list regarding this where I argued that
>> > > malloc(0) should not be an error and malloc should return a ptr != NULL
>> > > I guess that is why it hasn't been applied.
>> > >
>> > >  Jocke
>> >
>> > Ok, let's restart. Is there any objection why malloc(0) should not return
>> > NULL in uboot?
>>
>> Yes, read the thread to see why.
>
> Well I did, that's why I have no objections to applying this patch
>
>> > Is it coliding with any spec?
>>
>> No, both are valid.
>>

<quote author="Reinhard Meyer">
Out of principle I would say that malloc(0) should return a non-NULL
pointer of an area where exactly 0 bytes may be used. And, of course,
free() of that area shall not fail or crash the system.
</quote>

I'm wondering how exactly this would work - In theory, if you tried to
access this pointer you should get a segv. But I suppose if you malloc(1)
and try to access beyond the first byte there probably won't be a segv
either....

So to review the facts:

- The original complaint was that malloc(0) corrupts the malloc data
  structures, not that U-Boot's malloc(0) behaviour is non-standard
- Both the malloc(0) returns NULL and malloc(0) returns a uniquely
  free'able block of memory solutions are standard compliant
- malloc(0) returning NULL may break code which, for the sake of code
  simplicity, does not bother to check for zero-size before calling
  malloc()
- malloc(0) returning NULL may help to identify brain-dead use-cases

My vote:

        if ((long)bytes == 0) {
                DEBUG("Warning: malloc of zero block size\n");
                bytes = 1;
        } else if ((long)bytes < 0) {
                DEBUG("Error: malloc of negative block size\n");
                return 0;
        }

Regards,

Graeme


More information about the U-Boot mailing list