[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1358206649.32505.21@driftwood>
Date: Mon, 14 Jan 2013 17:37:29 -0600
From: Rob Landley <rob@...dley.net>
To: musl@...ts.openwall.com
Subject: Re: malloc(0) behaviour
On 01/14/2013 11:17:47 AM, Igmar Palsenberg wrote:
> Hi,
>
> Is there a (good) reason for Musl to follow glibc's malloc(0)
> behaviour ?
Because not doing so breaks some programs? (Dunno if it still does, but
last time I tried switching that config option off in uClibc the linux
from scratch build didn't finish.)
> Musl returns a valid pointer, which is fine according
> to the standard, but returning NULL is also fine.
>
> IMHO, returning NULL is better : It usually kills the program if
> actual storage is
> attempted.
It also kills the program if they're checking the return code of
malloc() and treating NULL as an allocation failure indicator. NULL has
a defined meaning of "failed", when a zero length allocation is trivial
to satisfy and not necessarily wrong.
Should a zero length file read return -1 instead of 0? Is it the
program's job to make sure it never makes a NOP syscall? Does adding
special case checks in your code to avoid such NOP calls actually make
the code smaller and simpler?
> You also can't do that if a valid pointer
> is returned, so I really can't grasp the reason for returning a
> pointer at all,
Not indicating that the allocation failed and triggering an assert()
when there isn't actually a problem with a legitimately zero length
array that had nothing in it? (Both times I debugged why LFS stuff was
failing that's what it turned out to be, but I didn't spend too much
time on it before just switching the uClibc option on to support it.)
> except to support buggy and lazy programming.
You're defining "lazy" here a "not adding a special case in the caller
for every use of malloc()". That's certainly a point of view, but I'm
not sure that's the word you want to use for it. "Not sufficiently
defensive programming" maybe?
Whether or not defensive programming is an improvement is one of those
perpetual arguments having to do with differing mindsets. In reality
the reason you'd want to do it is some libc implementations might _not_
allow malloc(0) to succeed, and thus there are portability issues. But
only for people who care about portability off glibc, which is an
uphill battle in the first place.
That said, "I'm right because other people might think like I do and
that would make me right" seems kind of a circular argument for a
position being _better_. If posix required a valid pointer to be
returned the positions would be reversed without any actual change in
the technical merits.
And "posix doesn't require this, therefore let's intentional break it
to force any programs with technical posix compatability issues to use
a different libc rather than change anything to humor us"... not seeing
it.
> I suggest we make malloc(0) return a NULL pointer. Any objections ?
Only that it broke real world programs last time I tried it, but if you
don't care about that then by all means force 'em to use a different
libc.
(Re: the "posix test" thread, having a ./configure --pedantic that
builds a musl without gnu/dammit extensions and safety tape over the
sharp bits sounds like a possible fun future thing. Having that be the
default, or adding a lot of runtime checks rather than commenting stuff
out at compile time, not so much...)
Rob
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
