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

[Mike Frysinger <vapier@gentoo.org>]

On Friday, October 22, 2010 12:40:07 Joakim Tjernlund wrote:
> Mike Frysinger wrote on 2010/10/22 17:18:05:
> > On Friday, October 22, 2010 04:34:52 Joakim Tjernlund wrote:
> > > Don't you want to know if the app screwed up or if the system is out
> > > of memory?
> > > 
> > > The only upside to malloc(0) == NULL I can see is an extra check
> > > for apps for which size == 0 is an error to the app too(something the
> > > app should have checked itself long before calling malloc).
> > 
> > if an app is doing malloc(0), it is broken.  i'm really not worried at
> > all
> 
> In your opinion, not mine and not POSIX either. I outlined uses for
> malloc(0) earlier.

i havent seen any realistic usage examples.  the only ones you quoted could 
easily be solved in a different way assuming they were even affected by 
malloc(0).

> > about detecting OOM state.  my real world experience thus far has shown
> > no actual problems with this behavior.  so unless you have some actual
> > examples where this behavior "harms" u-boot, i say we merge the OP's
> > patch.
> 
> Since you think an app is broken if it does malloc(0), it should not matter
> what malloc(0) returns to you. You only gain an extra error check for the
> broken app at the expense of ease of use and sane error checking in
> general.

more like you notice that the code is broken right away.  the few times i have 
seen a malloc(0), it was do to errors elsewhere in the code and once those 
were fixed, malloc() wasnt called with a size 0.

> I prefer not to make it easier for broken apps when it hurts elsewhere.

funny, i can use the same logic to ban malloc(0).  it makes you notice & fix 
errors without penalties.

> Ah, IT changed some settings globally. I changed it back. I hope this reply
> is better.

yes, this is much better.  thanks !
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20101022/0b9082f7/attachment.pgp