Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 15 Jan 2013 08:48:02 -0500
From: Rich Felker <dalias@...ifal.cx>
To: musl@...ts.openwall.com
Subject: Re: malloc(0) behaviour

On Tue, Jan 15, 2013 at 01:33:07PM +0100, Igmar Palsenberg wrote:
> 
> 
> >> While the above is clear to me, returning a pointer that can't hold anything just seems wrong to me.
> > 
> > i don't think we have too many options here,
> > the standards and historical practices has
> > various inconsistencies and musl has the least
> > broken one
> > 
> > but we can do a theoretical discussion about
> > the merits of malloc(0)!=0:
> > 
> > i'm surprised that it "seems wrong" to you,
> > you can access the amount of bytes you requested
> > through the returned pointer p, evaluating
> > p+size is valid, p is suitably aligned for all
> > objects and it can be freed.
> > these assumptions are broken if malloc(0)==0
> 
> That's there to access if size is 0 ? Sure, you can access :
> 
> struct foo {
> };

This is a constraint violation. C does not allow empty structs, and
even if it did, they would not have size 0, since no type or object
ever has size 0 in C.

> 
> which is size 0. I do wonder what that gives me in practice. That is, not counting the fact that :
> 
> if (size == 0)
> 	size = 1;
> 
> was a common practice in malloc() implementations a while ago.

Of course, this is the canonical, simplest way to make malloc(0)
return a unique pointer.

Rich

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.