Hi Marek, On Mon, Apr 2, 2012 at 10:13 AM, Marek Vasut <marek.va...@gmail.com> wrote: > Dear Graeme Russ, > >> Hi Marek, >> >> On Mon, Apr 2, 2012 at 9:45 AM, Marek Vasut <marek.va...@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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
