Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20250621162710.GK1827@brightrain.aerifal.cx>
Date: Sat, 21 Jun 2025 12:27:11 -0400
From: Rich Felker <dalias@...c.org>
To: Markus Wichmann <nullplan@....net>
Cc: musl@...ts.openwall.com, "Maciej W. Rozycki" <macro@...hat.com>,
	libc-alpha@...rceware.org, bug-gnulib@....org,
	наб <nabijaczleweli@...ijaczleweli.xyz>,
	Douglas McIlroy <douglas.mcilroy@...tmouth.edu>,
	Paul Eggert <eggert@...ucla.edu>,
	Robert Seacord <rcseacord@...il.com>,
	Elliott Hughes <enh@...gle.com>, Bruno Haible <bruno@...sp.org>,
	JeanHeyd Meneide <phdofthehouse@...il.com>,
	Adhemerval Zanella Netto <adhemerval.zanella@...aro.org>,
	Joseph Myers <josmyers@...hat.com>,
	Florian Weimer <fweimer@...hat.com>,
	Andreas Schwab <schwab@...e.de>, Thorsten Glaser <tg@...bsd.de>,
	Eric Blake <eblake@...hat.com>,
	Vincent Lefevre <vincent@...c17.net>,
	Mark Harris <mark.hsj@...il.com>,
	Collin Funk <collin.funk1@...il.com>,
	Wilco Dijkstra <Wilco.Dijkstra@....com>, DJ Delorie <dj@...hat.com>,
	Cristian Rodríguez <cristian@...riguez.im>,
	Siddhesh Poyarekar <siddhesh@...plt.org>,
	Sam James <sam@...too.org>, Mark Wielaard <mark@...mp.org>,
	Martin Uecker <ma.uecker@...il.com>,
	Christopher Bazley <chris.bazley.wg14@...il.com>,
	eskil@...ession.se
Subject: Re: Re: alx-0029r1 - Restore the traditional realloc(3)
 specification

On Sat, Jun 21, 2025 at 04:49:17PM +0200, Markus Wichmann wrote:
> Am Sat, Jun 21, 2025 at 04:07:54AM +0200 schrieb Alejandro Colomar:
> > I honestly still don't see the point in the camp returning NULL.  The
> > only reason it hasn't died, I think, is because of fear of breaking
> > existing code, but I don't see anyone asking for that behavior.
> > 
> 
> I invert the question: What is the point of requesting zero bytes? If
> you just want a pointer you cannot deref, but can validly plug into both
> realloc() and free(), I have this perfectly good null pointer right
> here. You can even statically initialize your variables with it. And you
> can easily tell it apart from pointers you can dereference.
> 
> I see malloc(0) as an error. According to all standards I could get my
> hands on, the argument to malloc is supposed to be the size of an
> object, and in C, there are no objects without type, and no zero-sized
> types. Maybe that's different in C++, I don't know. I have read a bit of
> C code in my life, and have written some as well, and debugged even more
> of it. I cannot recall an instance of anyone ever requesting to allocate
> zero bytes except in error (e.g. uncaught overflow).

Can we please not relitigate why people want this to work right? It's
actually not about any need for zero-sized allocations, but rather a
need for contractual consistency and avoiding violations of
least-surprise principle.

If malloc(0) or realloc(p,0) can return a null pointer for a condition
that's not a "failure", this means you eiter need error-path logic to
distinguish the "failure" from the "non-failure", or you need
entry-path logic to make sure 0 is never passed to malloc or realloc
as the result of any size computation.

We all know it's hard enough to get programmers to write even simple
error-path logic right with respect to malloc. So much code doesn't
even check the return value at all, or just aborts on a null return.

Likewise, it's hard enough to get programmers to write even simple
entry-path logic for allocation, avoiding integer overflows in the
computation of the size needed. Having to go to extra effort to also
avoid passing zero just makes a new non-forced footgun on top of the
other footguns that are more "essential".

Nobody wants the "make it worse" change you're asking for. So please
don't derail the work of people actually trying to make it better. At
least "we don't want to impose compatibility burdens on implementors
by forcing them to change something" is a reasonable argument some
folks might have against doing something here. "Let's make it worse
for nothing but ideological reasons" is not.

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.