Date: Fri, 30 Jun 2006 18:18:41 +0200 From: Bernd Walter <ticso@cicely12.cicely.de> To: freebsd-hackers@freebsd.org Subject: Re: Return value of malloc(0) Message-ID: <20060630161840.GU16775@cicely12.cicely.de> In-Reply-To: <20060630045937.GB97868@leiferikson.flosken.lan> References: <20060628181045.GA54915@curry.mchp.siemens.de> <20060629054222.GA92895@leiferikson.flosken.lan> <m3bqsceyf2.fsf@merlin.emma.line.org> <20060629162319.GA94921@leiferikson.flosken.lan> <m33bdnhnv7.fsf@merlin.emma.line.org> <20060630045937.GB97868@leiferikson.flosken.lan>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Jun 30, 2006 at 06:59:37AM +0200, Johannes Weiner wrote: > Hi, > > On Thu, Jun 29, 2006 at 07:29:16PM +0200, Matthias Andree wrote: > > No, sir. Operator precedence: assign first, and then compare, thus the > > comparison will always be true (else you'd be comparing to undefined > > values, which isn't any better). You might as well write: > > > > foo = malloc(0); > > /* make noise */ > > Ok, just for having it done: > > if (foo == (foo = some_val)) > > .. would be right to check if foo stayed the same. No? > > > There is no way to see a 0x800 return from malloc(0) as "error". > > So noone should actually use malloc(0) and check the size_t argument before > passing it, I guess. But noone should dereference something beyound malloc'ed size. The following code is broken no matter if x is 0 or anything else, you always end up accessing data beyond allocated range: foo = malloc(x); foo[x] = bar; It might be Ok not to check x when calling malloc, but is always required to check if you access something outside the malloc'ed range unless you can trust your size - in which case you wouldn't had malloc'ed zero bytes anyway. -- B.Walter http://www.bwct.de http://www.fizon.de bernd@bwct.de info@bwct.de support@fizon.de
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060630161840.GU16775>