From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 28 20:19:37 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 A4A8516A403 for ; Wed, 28 Jun 2006 20:19:37 +0000 (UTC) (envelope-from lgusenet@be-well.ilk.org) Received: from mail8.sea5.speakeasy.net (mail8.sea5.speakeasy.net [69.17.117.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 40CE14498F for ; Wed, 28 Jun 2006 20:19:37 +0000 (GMT) (envelope-from lgusenet@be-well.ilk.org) Received: (qmail 22194 invoked from network); 28 Jun 2006 20:19:36 -0000 Received: from dsl092-078-145.bos1.dsl.speakeasy.net (HELO be-well.ilk.org) ([66.92.78.145]) (envelope-sender ) by mail8.sea5.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 28 Jun 2006 20:19:36 -0000 Received: by be-well.ilk.org (Postfix, from userid 1147) id 0D91128449; Wed, 28 Jun 2006 16:19:35 -0400 (EDT) To: Andre Albsmeier References: <20060628181045.GA54915@curry.mchp.siemens.de> From: Lowell Gilbert Date: Wed, 28 Jun 2006 16:19:35 -0400 In-Reply-To: <20060628181045.GA54915@curry.mchp.siemens.de> (Andre Albsmeier's message of "Wed, 28 Jun 2006 20:10:45 +0200") Message-ID: <44wtb12fu0.fsf@be-well.ilk.org> User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailman-Approved-At: Wed, 28 Jun 2006 21:38:12 +0000 Cc: freebsd-hackers@freebsd.org 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: Wed, 28 Jun 2006 20:19:37 -0000 Andre Albsmeier writes: > > The manpage makes me think that when malloc is called with 0 > as argument (and no V-flag had been set) the pointer it returns > can actually be used (as a pointer to the so-called "minimal > allocation"). It seems, that firefox "thinks" the same way :-). > However, it is calculated in malloc.c as a constant and is > always 0x800 (on my architecture). Any access to this area > results in a SIGSEV. The C standard explicitly allows both behaviours, and requires the implementation to choose one of them. If it returns a non-NULL pointer, though, that pointer can *only* be used for passing back to free(). It may *not* be dereferenced. So firefox is wrong, and actually broken. > I assume the behaviour is meant to show up programming errors: > > "If you use malloc(0) and are crazy enough to access the 'allocated' > memory we give you a SIGSEV to show you how dumb you are :-)". Yes. > In this case the manpage is wrong (or, at least, mis-leading) and > should be fixed (I could give it a try if someone actually is willing > to commit it). I don't see what you are claiming is wrong. Can you give a brief description of you're suggesting. > Apart from that, I suggest, we should run firefox (and maybe other > mozilla apps) with MALLOC_OPTIONS=V. That would be reasonable, particularly for the time being. However, the firefox bug really should be fixed in the upstream sources. Writing past the end of an allocated buffer (which is what the code does, if you think about it) is a serious error. > Another position could be that firefox is wrong because it NEVER > may use ANY return value of a malloc(0), regardless of its content. The C language standard agrees with this position...