Dear Graeme Russ, > 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.
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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
