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

Graeme Russ
2012-04-02T20:59:57Z

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