From owner-freebsd-hackers@FreeBSD.ORG Thu Jun 29 17:45:49 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 3372216A412 for ; Thu, 29 Jun 2006 17:45:49 +0000 (UTC) (envelope-from Hartmut.Brandt@dlr.de) Received: from smtp-3.dlr.de (smtp-3.dlr.de [195.37.61.187]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8575643D6E for ; Thu, 29 Jun 2006 17:45:42 +0000 (GMT) (envelope-from Hartmut.Brandt@dlr.de) Received: from beagle.kn.op.dlr.de ([129.247.173.6]) by smtp-3.dlr.de over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Thu, 29 Jun 2006 19:45:41 +0200 Date: Thu, 29 Jun 2006 19:45:40 +0200 (CEST) From: Harti Brandt X-X-Sender: brandt_h@beagle.kn.op.dlr.de To: Matthias Andree In-Reply-To: Message-ID: <20060629194138.S55888@beagle.kn.op.dlr.de> References: <20060628181045.GA54915@curry.mchp.siemens.de> <20060629054222.GA92895@leiferikson.flosken.lan> <20060629162319.GA94921@leiferikson.flosken.lan> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-OriginalArrivalTime: 29 Jun 2006 17:45:41.0189 (UTC) FILETIME=[D6C5A750:01C69BA3] 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 Reply-To: Harti Brandt 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 17:45:49 -0000 On Thu, 29 Jun 2006, Matthias Andree wrote: MA>Johannes Weiner writes: MA> MA>> On Thu, Jun 29, 2006 at 06:09:37PM +0200, Matthias Andree wrote: MA>> MA>>> The value returned from malloc(0) must not be dereferenced whatever it MA>>> was. It was 0x800, which doesn't count as "failure". MA>> MA>> But this would be appropriate for catching the error: MA>> MA>> if ((foo = malloc(0)) == foo) MA>> /* make noise */ MA>> MA>> wouldn't it? MA> MA>No, sir. Operator precedence: assign first, and then compare, thus the MA>comparison will always be true (else you'd be comparing to undefined MA>values, which isn't any better). You might as well write: Operator precedence is just for parsing, not for evaluation. The compiler may well first evaluate the foo on the right side of the == (by fetching it) and then go an call malloc and assign foo. It is actually undefined behaviour, I think, so it may well make explode your near-by atom power plant. harti MA> MA> foo = malloc(0); MA> /* make noise */ MA> MA>There is no way to see a 0x800 return from malloc(0) as "error". MA> MA>