[U-Boot] [PATCH] Prevent malloc with size 0

[Graeme Russ]

Hi Jocke

On Tue, Apr 3, 2012 at 7:14 AM, Joakim Tjernlund
<joakim.tjernlund at transmode.se> wrote:
> Graeme Russ <graeme.russ at gmail.com> wrote on 2012/04/02 22:59:57:
>>
>>
>> On Apr 3, 2012 6:57 AM, "Joakim Tjernlund" <joakim.tjernlund at transmode.se> wrote:
>> >
>> > Graeme Russ <graeme.russ at gmail.com> wrote on 2012/04/02 22:28:46:
>> > > From: Graeme Russ <graeme.russ at gmail.com>
>> > >
>> > > On 04/02/2012 05:40 PM, Joakim Tjernlund wrote:
>> > > > Hi Grame
>> > > >
>> > > > Graeme Russ <graeme.russ at 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