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

Joakim Tjernlund
2010-10-22T08:34:52Z

Mike Frysinger <vapier@gentoo.org> wrote on 2010/10/22 09:55:49:
>
> On Friday, October 22, 2010 03:37:43 Joakim Tjernlund wrote:
> > Mike Frysinger wrote on 2010/10/22 09:20:22:
> > > On Friday, October 22, 2010 02:10:16 Joakim Tjernlund wrote:
> > > > does not set errno which screws error handling. One have to bend
over
> > > > just to cope with this.
> > >
> > > that depends on your implementation. in u-boot, there really is no
> > > "errno"
> >
> > Yes, and that and that is even worse. How do you tell if you are out
of
> > memory or not? Checking size == 0 after the fact? Then you could do
that
> > before calling malloc in the first place.
>
> i still dont see any real world (or even theoretical) need for
malloc(0). so
> the issue of error checking is irrelevant until you can come up with
one.

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

>
> > > the concept of an invalid pointer is pretty arch-specific. and it
changes
> > > the semantics of what the vast majority of coders (and their code)
out
> > > there expect -- NULL means error while non-NULL means success.
> >
> > hardly as glibc returns a non NULL ptr. Changing this would probably
> > break apps, making them think they are out of memory.
>
> funny because i have no problem running software on top of uClibc. and
it
> does do malloc(0) == NULL.
>
> just visit http://wh0rd.org/ and marvel at all the software running
perfectly
> fine on uClibc. apache/openssh/openvpn/php/gd/git/svn/...
>
> > non null still what it is supposed to mean, you successfully allocated
> > 0 bytes.
>
> POSIX clearly labels it "implementation defined" which means "no sane
portable
> programmer may rely on its behavior"

Yes and that is probably why you don't see any problems. Apps has learned
this
the hard way and coded accordingly to avoid problems. That doesn't mean
anything w.r.t what is the better behaviour from malloc(0)

>
> > > a better question might be "why isnt a NULL pointer on your platform
an
> > > invalid pointer" ? ive added a simple CONFIG define for Blackfin
users
> > > to do just that -- make access to the low 1KiB of memory generate an
> > > exception. it does so with pretty much 0 runtime overhead.
> >
> > You lost me here. How does this relate to the issue before us?
>
> you're asking for an invalid pointer. the presumption is that you want
it so
> that attempts to access it will fail. if that isnt the case, i have no
idea
> why you want malloc(0) to return an "invalid pointer" that isnt NULL.

ah, I guess asking for invalid ptrs in u-boot is too much for a boot app
so
lets forget about that.

>
> btw, could you please fix your mailer. it constantly destroys quoted
context.

I wish, we use Lotus/Domino here nowdays. I have sent numerous reports
to IBM about their crappy email support. I have been promised they
will fix some of them to the next release but I am not holding my breath
:(

hmm, "destroys quoted context", I think that is a new one. What
exactly is destroyed?