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

Joakim Tjernlund joakim.tjernlund at transmode.se
Mon Apr 2 22:56:58 CEST 2012


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:
> >>
> >> 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.
>
> 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.

  Jocke



More information about the U-Boot mailing list