Graeme Russ <graeme.r...@gmail.com> wrote on 2012/04/02 22:59:57: > > > On Apr 3, 2012 6:57 AM, "Joakim Tjernlund" <joakim.tjernl...@transmode.se> > wrote: > > > > Graeme Russ <graeme.r...@gmail.com> wrote on 2012/04/02 22:28:46: > > > From: Graeme Russ <graeme.r...@gmail.com> > > > > > > On 04/02/2012 05:40 PM, Joakim Tjernlund wrote: > > > > 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. > > > > > > As per the spec: > > > > > > The malloc function returns either a null pointer or a pointer to the > > > allocated space. > > > > > > The amount of storage allocated by a successful call to the calloc, > > > malloc, > > > or realloc function when 0 bytes was requested (7.22.3). > > > > > > The way I read that, if NULL is not returned, then what is returned is a > > > pointer to allocated space. If malloc(0) is called, the amount of space > > > allocated is not determined by the spec > > > > Please read http://lwn.net/Articles/236920/ > > They have a different view. > Yes, I read that. They also have a compelling argument. > Bottom line is, all three solutions are valid because, at the end of the day, > it's up to the caller to handle the unspecified behaviour.
If you write code in general yes, for kernel no. We also know that many devs. doesn't know there is a difference. This is not really the question here though. It is: what method should u-boot malloc impl.? I say that selecting NULL is the worst(in this long thread I have motivated why too) Jocke _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
