Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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

Your e-mail address:

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.