[U-Boot] [PATCH] Prevent malloc with size 0
Graeme Russ
graeme.russ at gmail.com
Mon Apr 2 09:17:44 CEST 2012
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
> 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...
Regards,
Graeme
More information about the U-Boot
mailing list