vapierfil...@gmail.com wrote on 2012/04/02 21:14:14: > > On Mon, Apr 2, 2012 at 14:40, Joakim Tjernlund wrote: > > Marek Vasut <marek.va...@gmail.com> wrote on 2012/04/02 20:00:03: > >> Dear Joakim Tjernlund, > >> > Depends, if writing generic code for lots of OS:es you cannot rely > >> > malloc(0). Writing kernel code you can. > >> > >> No you cannot. It's in the spec you cannot and you have to behave > >> according to > >> the spec, not according to kernel. > > > > How so? The kernel is its own system and has it own rules and it is wise > > to follow them. > > correct > > >> > From Scotts example we already know there is kernel code that relies on > >> > malloc(0) not returning NULL. > >> > >> Sure, but that means the code is messed up. > > > > ohh, I don't think the kernel people will agree: > > http://lwn.net/Articles/236920/ > > But feel free to bring it up. > > i dislike the malloc(0) returning valid memory, but i'm fine with the > ZERO_SIZE_PTR idea. i think we'd have to delegate this to arches > though to pick a pointer that'd work for them ... certainly the kernel > definition won't work for us: > #define ZERO_SIZE_PTR ((void *)16) > > address 0 and higher is valid memory on many platforms. for Blackfin > systems, (-16) should work.
Finding an invalid address would be ideal, but that might be hard even in arch code. kmalloc(0) used to return a valid ptr up to 2.6.23 so this was never a big problem. I guess one could try finding an invalid address in arch code anyway but let board code override it if needed. _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot