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

[Marek Vasut]

Dear Graeme Russ,

> Hi Marek,
> 
> On Mon, Apr 2, 2012 at 10:13 AM, Marek Vasut <marek.vasut at gmail.com> wrote:
> > Dear Graeme Russ,
> > 
> >> Hi Marek,
> >> 
> >> On Mon, Apr 2, 2012 at 9:45 AM, Marek Vasut <marek.vasut at gmail.com> wrote:
> >> > Dear Graeme Russ,
> >> 
> >> Because you just set it off - Right now, that code is assuming malloc(0)
> >> will return a valid pointer and thus not throw an E_NOMEM error - Now
> >> all that code will fail with E_NOMEM
> > 
> > Well ... that code worked with invalid memory (most probably not even R/W
> > because it was some completely random hunk) and worked only by sheer
> > coincidence. Let's break it, it was broken anyway.
> 
> a) The code calling malloc(0) is not broken, U-Boot's implementation of
>    malloc(0) is.

Well if it corrupts the internal structures of the mallocator, it's broken 
because it works by sheer coincidence. But I know what you wanna point out.

> b) The code calling malloc(0) is making a perfectly legitimate assumption
>    based on how glibc handles malloc(0)

Yes, agreed

> c) Just because glibc does something does not mean we have to

ACK

> d) malloc(0) returning NULL and malloc(0) returning a valid pointer is not
>    going to trouble me as I will never call malloc(0)

You sure? :)

Anyway, if we return something else than 0, how are we gonna trap such a null 
pointer?

> > Do you know about any such code? That's why I suggest adding such a
> > debug() only in case there's malloc(0) called. Maybe even add a printf()
> > instead.
> 
> Did you see the FDT example - Admitedly not in U-Boot but it's a really
> good example IMHO - For the sake of code simplisity and clarity, some
> processing loops are best implemented assuming malloc(0) will return
> a valid pointer. Now if that pointer is de-referenced, then that is
> the callers problem...

I did not see it, where?

> 
> Regards,
> 
> Graeme

Best regards,
Marek Vasut