[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20130115134802.GY20323@brightrain.aerifal.cx>
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
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
