Hi Jocke On Tue, Apr 3, 2012 at 7:14 AM, Joakim Tjernlund <joakim.tjernl...@transmode.se> wrote: > 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:
[snip] >> > > >> 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) This thread both fascinates and annoys me... I've changed my position on this issue several times, which to me indicates that it does not really bother me that much which way we go... As the kernel guys point out, returning non-NULL has a distinct code simplicity advantage (especially when compile-time options can reduce some data structures or other allocations to zero size) And I really need to check, but I have a sneaking suspicion that as the code currently stands in U-Boot/x86 dereferencing a NULL pointer won't cause an exception. In x86, U-Boot configures all protected mode segments to be 4GB starting at physical address 0x00000000 with no virtual address translation. Accessing physical address 0x00000000 is just as valid as accessing 0x00000001 (or any other address). Now if I set segments to start at 0x00000002 then I can trap a segmentation fault for accesses to 0x00000000 (NULL) and 0x00000001 (malloc(0) pointer) That will mean that U-Boot cannot ever access those two bytes of memory, but I doubt that I would ever want to. And I will need to set the segments to base address 0x00000000 before jumping into Linux... Let me have a play tonight Regards, Graeme _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
