Date: Mon, 01 Mar 2004 17:37:31 +0100 From: "Poul-Henning Kamp" <phk@phk.freebsd.dk> To: David Schultz <das@FreeBSD.ORG> Cc: freebsd-standards@FreeBSD.ORG Subject: Re: standards/62858: malloc(0) not C99 compliant Message-ID: <59773.1078159051@critter.freebsd.dk> In-Reply-To: Your message of "Mon, 01 Mar 2004 08:00:22 PST." <20040301160022.GA13617@VARK.homeunix.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <20040301160022.GA13617@VARK.homeunix.com>, David Schultz writes: >On Mon, Mar 01, 2004, Poul-Henning Kamp wrote: >> In message <xzpznb0iwm0.fsf@dwp.des.no>, Dag-Erling =?iso-8859-1?q?Sm=F8rgrav?= >> writes: >> >Poul-Henning Kamp <phk@FreeBSD.org> writes: >> >> This is a deliberate choice. Handling zero-size pointers correctly >> >> in malloc(3) would be a rather involved and is currently not high >> >> on the todolist. A good patch might change that. >> > >> >The standard does allow returning NULL, you know. >> >> Yes, but unfortunately that broke more software than I cared for >> arguing with authors about. > >Several other malloc implementations do this, including the one in >Tru64. But assuming that there really are lots of broken >applications out there, what's wrong with simply converting >malloc(0) calls to malloc(1) calls? I want to make sure people who malloc(0) and then deref the pointer get the core dump they need to debug their problem. But lets turn this around, do you have evidence of code which breaks with the current behaviour ? Does the code also fail if you give malloc the 'V' flag ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?59773.1078159051>