From owner-freebsd-hackers@FreeBSD.ORG Fri Jun 30 16:31:02 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 9113216A534 for ; Fri, 30 Jun 2006 16:31:02 +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 9A91543D95 for ; Fri, 30 Jun 2006 16:30:43 +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 1FwLwP-0007QL-Pl; Fri, 30 Jun 2006 09:34:03 -0700 Date: Fri, 30 Jun 2006 12:30:13 -0400 From: Pat Lashley To: Johannes Weiner , freebsd-hackers@freebsd.org Message-ID: <417C9B11412FF8C17A1AD483@Zelazny> In-Reply-To: <20060630045937.GB97868@leiferikson.flosken.lan> References: <20060628181045.GA54915@curry.mchp.siemens.de> <20060629054222.GA92895@leiferikson.flosken.lan> <20060629162319.GA94921@leiferikson.flosken.lan> <20060630045937.GB97868@leiferikson.flosken.lan> X-Mailer: Mulberry/4.0.0 (Mac OS X) MIME-Version: 1.0 X-Scan-Signature: 976632dbfefb5aa7849fdff075a724fbc0b8d439 X-Spam-User: nobody X-Spam-Score: -4.1 (----) X-Spam-Score-Int: -40 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: (-4.1 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.6 AWL AWL: Auto-whitelist adjustment X-Mailman-Approved-At: Fri, 30 Jun 2006 16:35:11 +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:31:02 -0000 > > 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? No. As far as I know, there is no requirement in the standard that the left side of an inequality be evaluated before the right side; or that there is any need for consistency in order of evaluation. (And even if I'm wrong and the C standard does specify evaluation order, other languages may not; so depending on it would be a bad habit to form.) > > There is no way to see a 0x800 return from malloc(0) as "error". The point is that that value is NOT an error indicator at all. (As discussed elsewhere, it isn't quite standards-compliant; since we always return the same value for malloc(0); but the malloc -did- succeed.) > So noone should actually use malloc(0) and check the size_t argument before > passing it, I guess. The error was later when they attempted to de-reference the pointer returned from the 'malloc(0)'; not in the allocation itself. BUT, that said, the safest and most portable coding practice would be: // The C standard does not require malloc(0) to return NULL; // but whatever it returns MUST NOT be dereferenced. ptr = ( size == 0 ) ? NULL : malloc( size ) ; -Pat