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.