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

2 Apr 2012


      On Apr 3, 2012 6:57 AM, "Joakim Tjernlund" joakim.tjernlund@transmode.se
wrote:
...
Graeme Russ graeme.russ@gmail.com wrote on 2012/04/02 22:28:46:
...
From: Graeme Russ graeme.russ@gmail.com
On 04/02/2012 05:40 PM, Joakim Tjernlund wrote:
...
Hi Grame
Graeme Russ graeme.russ@gmail.com wrote on 2012/04/02 09:17:44:
...
Hi Joakim,
On Apr 2, 2012 4:55 PM, "Joakim Tjernlund" <
joakim.tjernlund@transmode.se> wrote:
...
...
...
...
...
...
Hi Marek,
On Mon, Apr 2, 2012 at 1:36 PM, Marek Vasut marek.vasut@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.
Regards,
Graeme