From owner-freebsd-hackers@FreeBSD.ORG Fri Jun 30 16:15:53 2006 Return-Path: X-Original-To: freebsd-hackers@freeBSD.org Delivered-To: freebsd-hackers@freeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5132816A403 for ; Fri, 30 Jun 2006 16:15:53 +0000 (UTC) (envelope-from patl+freebsd@volant.org) Received: from smtp.volant.org (gate.volant.org [207.111.218.246]) by mx1.FreeBSD.org (Postfix) with ESMTP id CA0F144529 for ; Fri, 30 Jun 2006 16:15:52 +0000 (GMT) (envelope-from patl+freebsd@volant.org) Received: from adsl-065-081-071-131.sip.gnv.bellsouth.net ([65.81.71.131] helo=[172.19.1.100]) by smtp.volant.org with asmtp (TLSv1:AES256-SHA:256) (Exim 4.34 (FreeBSD)) id 1FwLi2-0007GY-3A for freebsd-hackers@freeBSD.org; Fri, 30 Jun 2006 09:19:13 -0700 Date: Fri, 30 Jun 2006 12:15:21 -0400 From: Pat Lashley To: freebsd-hackers@freeBSD.org Message-ID: <2FCF78FADC5CAB74EF6D9405@Zelazny> In-Reply-To: <44odwbu1cu.fsf@be-well.ilk.org> References: <20060628181045.GA54915@curry.mchp.siemens.de> <20060628212956.GI822@wombat.fafoe.narf.at> <805AA34B676EDF411B3CF548@Zelazny> <20060629165629.GA6875@britannica.bec.de> <44odwbu1cu.fsf@be-well.ilk.org> X-Mailer: Mulberry/4.0.0 (Mac OS X) MIME-Version: 1.0 X-Scan-Signature: 5c473f650f45eac5f4dc7c2a2dc1afe01d8c87bb X-Spam-User: nobody X-Spam-Score: -3.9 (---) X-Spam-Score-Int: -38 X-Spam-Report: This mail has matched the spam-filter tests listed below. See http://spamassassin.org/tag/ for details about the specific tests reported. In general, the higher the number of total points, the more likely that it actually is spam. (The 'required' number of points listed below is the arbitrary number above which the message is normally considered spam.) Content analysis details: (-3.9 points total, 5.0 required) 0.1 HTML_MESSAGE BODY: HTML included in message 0.1 HTML_FONTCOLOR_RED BODY: HTML font color is red -4.9 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] 0.8 AWL AWL: Auto-whitelist adjustment X-Mailman-Approved-At: Fri, 30 Jun 2006 16:35:00 +0000 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Re: Return value of malloc(0) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jun 2006 16:15:53 -0000 > I went wandering through the C Working Group archives for the heck of > it, and apparently a lot of people were confused over this, thinking > either as you did or that "unique" meant it would a value unique to > the usage of malloc(0). It's been clarified recently (and will be in > the next revision of the standard) to the meaning you understood. > > Specifically: > > If the size of the space requested is zero, the behavior is > implementation-defined: either a null pointer is returned, or the > behavior is as if the size were some nonzero value, except that > the returned pointer shall not be used to access an object. > > > But if it did actually perform a > > minimum allocation'; wouldn't it have to return a different value > > every time to maintain the free() semantics? > > I think that's another way of looking at the same confusion. If > "minimum" is zero, then using a sentinel value (as in FreeBSD) works. But the standard, as you quoted above, says 'as if the size were some NONZERO value'; so using a sentinel value is NOT standards-compliant. > Our malloc() could be easily fixed to be standards-compliant by > removing the special handling for ZEROSIZEPTR in malloc.c; then > allocations of 0 bytes will be rounded up to 16, just like all other > alloations of less than 16 bytes. However, that would lose much of > the bug-finding advantage of the current behaviour. But how often does this particular type of bug occur? If often enough, how hard would it be to make zero-sized allocations come from some special chunk of address space that is reserved to always generate a fault on access (from user space)? (And, of course, fix realloc() to recognize pointers in that range and do the right thing.) Also, under what circumstances could a zero-sized allocation fail (using our current scheme)? Is it really useful to maintain the distinction between 'failed' and 'successfully allocated no space'? Would it be better to just take the simple route of returning NULL for zero-sized allocations? > This is wandering into -standards territory, though. In any case, the > answer to thread's original question is "mozilla should fix its code > to not assume malloc(0)==NULL". Agreed. (With the usual observation that they, too, are a mainly volunteer-based project; and would probably appreciate the inclusion of a patch with the bug report. And, of course, that the original poster of this thread should file a bug report with the Mozilla project.) -Pat