From owner-freebsd-hackers@FreeBSD.ORG Thu Jun 29 12:21:13 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 C682916A403 for ; Thu, 29 Jun 2006 12:21:13 +0000 (UTC) (envelope-from Andre.Albsmeier@siemens.com) Received: from thoth.sbs.de (thoth.sbs.de [192.35.17.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 19AE543D46 for ; Thu, 29 Jun 2006 12:21:12 +0000 (GMT) (envelope-from Andre.Albsmeier@siemens.com) Received: from mail2.siemens.de (localhost [127.0.0.1]) by thoth.sbs.de (8.12.6/8.12.6) with ESMTP id k5TCL8e1008260; Thu, 29 Jun 2006 14:21:08 +0200 Received: from ims.mchp.siemens.de (ims.mchp.siemens.de [139.25.31.39]) by mail2.siemens.de (8.12.6/8.12.6) with ESMTP id k5TCL7LM031746; Thu, 29 Jun 2006 14:21:08 +0200 Received: from mail-ct.mchp.siemens.de (mail-ct.mchp.siemens.de [139.25.31.51]) by ims.mchp.siemens.de with ESMTP id k5TCL7JQ014077; Thu, 29 Jun 2006 14:21:07 +0200 (MEST) Received: from curry.mchp.siemens.de (curry [139.25.40.130]) by mail-ct.mchp.siemens.de (8.12.11/8.12.11) with ESMTP id k5TCL7Ox006533; Thu, 29 Jun 2006 14:21:07 +0200 (MEST) Received: (from localhost) by curry.mchp.siemens.de (8.13.6/8.13.6) id k5TCL6hD054619; Date: Thu, 29 Jun 2006 14:21:06 +0200 From: Andre Albsmeier To: Lowell Gilbert Message-ID: <20060629122106.GA79420@curry.mchp.siemens.de> References: <20060628181045.GA54915@curry.mchp.siemens.de> <44wtb12fu0.fsf@be-well.ilk.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <44wtb12fu0.fsf@be-well.ilk.org> X-Echelon: X-Advice: Drop that crappy M$-Outlook, I'm tired of your viruses! User-Agent: Mutt/1.5.11 Cc: freebsd-hackers@freebsd.org, Andre Albsmeier 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: Thu, 29 Jun 2006 12:21:14 -0000 On Wed, 28-Jun-2006 at 16:19:35 -0400, Lowell Gilbert wrote: > 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. Very good. I am glad this is clearly defined. > > > 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 It says: "The default behavior is to make a minimal allocation and return a pointer to it." This sounds as if it allocated some (!) bytes so the application can use it. Yes, I know that 0 would be minimal as well :-). And if you look into malloc.c you will see that, in fact, it doesn't allocate anything at all: } else if (!size) { if (ptr != NULL) ifree(ptr); r = ZEROSIZEPTR; r ist returned later and ZEROSIZEPTR is a constant. > description of you're suggesting. Hmm, let's see: The default behavior is to return a non-NULL pointer which may be passed to free() but does not point to any memory which can be used by the application. > > > 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. In this case, yes, of course. -Andre > 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... -- Micro$oft: When will your system crash today?