Hi Marek,
On Mon, Apr 2, 2012 at 10:13 AM, Marek Vasut marek.vasut@gmail.com wrote:
Dear Graeme Russ,
Hi Marek,
On Mon, Apr 2, 2012 at 9:45 AM, Marek Vasut marek.vasut@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.
b) The code calling malloc(0) is making a perfectly legitimate assumption based on how glibc handles malloc(0)
c) Just because glibc does something does not mean we have to
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)
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...
Regards,
Graeme