Dear Joakim Tjernlund, > Hi Grame > > Graeme Russ <graeme.r...@gmail.com> wrote on 2012/04/02 09:17:44: > > Hi Joakim, > > > > On Apr 2, 2012 4:55 PM, "Joakim Tjernlund" <joakim.tjernl...@transmode.se> wrote: > > > > Hi Marek, > > > > > > > > On Mon, Apr 2, 2012 at 1:36 PM, Marek Vasut <marek.va...@gmail.com> wrote: > > > > > Dear Mike Frysinger, > > > > > > > > > >> On Sunday 01 April 2012 20:25:44 Graeme Russ wrote: > > > > >> > b) The code calling malloc(0) is making a perfectly legitimate > > > > >> > assumption > > > > >> > > > > > >> > based on how glibc handles malloc(0) > > > > >> > > > > >> not really. POSIX says malloc(0) is implementation defined (so it > > > > >> may return a unique address, or it may return NULL). no > > > > >> userspace code assuming malloc(0) will return non-NULL is > > > > >> correct. > > > > > > > > > > Which is your implementation-defined ;-) But I have to agree with > > > > > this one. So my vote is for returning NULL. > > > > > > > > Also, no userspace code assuming malloc(0) will return NULL is > > > > correct > > > > > > > > Point being, no matter which implementation is chosen, it is up to > > > > the caller to not assume that the choice that was made was, in fact, > > > > the choice that was made. > > > > > > > > I.e. the behaviour of malloc(0) should be able to be changed on a > > > > whim with no side-effects > > > > > > > > So I think I should change my vote to returning NULL for one reason > > > > and one reason only - It is faster during run-time > > > > > > Then u-boot will be incompatible with both glibc and the linux kernel, > > > it seems > > > > Forget aboug other implementations... > > What matters is that the fact that the behaviour is undefined and it is > > up to the caller to take that into account > > Well, u-boot borrows code from both kernel and user space so it would make > sense if malloc(0) behaved the same. Especially for kernel code which tend > to depend on the kernels impl.(just look at Scotts example) > > > > to me that any modern impl. of malloc(0) will return a non NULL ptr. > > > > > > It does need to be slower, just return ~0 instead, the kernel does > > > something similar: if (!size) > > > return ZERO_SIZE_PTR; > > > > That could work, but technically I don't think it complies as it is not a > > pointer to allocated memory... > > It doesn't not have to be allocated memory, just a ptr != NULL which you > can do free() on.
But kernel has something mapped there to trap these pointers I believe. > > Jocke Best regards, Marek Vasut _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
