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

[Joakim Tjernlund]

Marek Vasut <marek.vasut at gmail.com> wrote on 2012/04/02 16:05:13:
>
> Dear Joakim Tjernlund,
>
> > Hi Grame
> >
> > Graeme Russ <graeme.russ at gmail.com> wrote on 2012/04/02 09:17:44:
> > > Hi Joakim,
> > >
> > > On Apr 2, 2012 4:55 PM, "Joakim Tjernlund" <joakim.tjernlund at transmode.se>
> wrote:
> > > > > Hi Marek,
> > > > >
> > > > > On Mon, Apr 2, 2012 at 1:36 PM, Marek Vasut <marek.vasut at 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.
>
> But kernel has something mapped there to trap these pointers I believe.

So? That only means that the kernel has extra protection if someone tries to
deference such a ptr. You are not required to do that(nice to have though)
You don have any protection for deferencing NULL either I think?

 Jocke