Dear Graeme Russ,
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.
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