Return-Path: <awaresystems.be+caf_=filtered=awaresystems.be@gmail.com>
Delivered-To: filtered@awaresystems.be
Received: from mx-q.one.com (mx-q.one.com [91.198.169.248])
	by mail6.local (Postfix) with ESMTP id C715E80150A63
	for <filtered@awaresystems.be>; Thu, 13 Dec 2012 01:29:03 +0100 (CET)
X-Virus-Scanned: by one.com
Received-SPF: pass (mx-q: domain of awaresystems.be+caf_=filtered=awaresystems.be@gmail.com designates 209.85.223.176 as permitted sender)
X-Greylist: whitelisted by SQLgrey-1.8.0-rc2
Received: from mail-ie0-f176.google.com (mail-ie0-f176.google.com [209.85.223.176])
	by mx-q.one.com (Postfix) with ESMTP id 602021412
	for <filtered@awaresystems.be>; Thu, 13 Dec 2012 00:29:03 +0000 (UTC)
Received: by mail-ie0-f176.google.com with SMTP id 13so3075742iea.21
        for <filtered@awaresystems.be>; Wed, 12 Dec 2012 16:29:02 -0800 (PST)
Received: by 10.50.5.177 with SMTP id t17mr2685884igt.48.1355358542396;
        Wed, 12 Dec 2012 16:29:02 -0800 (PST)
X-Forwarded-To: filtered@awaresystems.be
X-Forwarded-For: awaresystems.be@gmail.com filtered@awaresystems.be
Delivered-To: awaresystems.be@gmail.com
Received: by 10.42.44.135 with SMTP id b7csp240212icf;
        Wed, 12 Dec 2012 16:29:01 -0800 (PST)
Received: by 10.52.37.103 with SMTP id x7mr1913526vdj.61.1355358540687;
        Wed, 12 Dec 2012 16:29:00 -0800 (PST)
Received-SPF: neutral (google.com: 91.198.169.250 is neither permitted nor denied by best guess record for domain of tiff-bounces@lists.maptools.org) client-ip=91.198.169.250;
Received: by 10.230.201.143 with POP3 id fa15mf1419909vbb.27;
        Wed, 12 Dec 2012 16:29:00 -0800 (PST)
X-Gmail-Fetch-Info: info@awaresystems.be 1 pop.awaresystems.be 110 info@awaresystems.be
Delivered-To: info@awaresystems.be
Received: from mx-s.one.com (mx-s.one.com [91.198.169.250])
	by mail6.local (Postfix) with ESMTP id BFF4C80150A63
	for <info@awaresystems.be>; Thu, 13 Dec 2012 00:44:49 +0100 (CET)
X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0-rc2
Received: from lists.maptools.org (lists.maptools.org [65.39.174.144])
	by mx-s.one.com (Postfix) with ESMTP id 6122766C3D5
	for <info@awaresystems.be>; Wed, 12 Dec 2012 23:44:49 +0000 (UTC)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
	by lists.maptools.org (Postfix) with ESMTP id 58FCB43A014;
	Wed, 12 Dec 2012 18:43:12 -0500 (EST)
Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130])
	by lists.maptools.org (Postfix) with ESMTP id 26A8143A014
	for <tiff@lists.maptools.org>; Wed, 12 Dec 2012 18:42:40 -0500 (EST)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
	by sss.pgh.pa.us (8.14.5/8.14.5) with ESMTP id qBCNgj6H017656
	for <tiff@lists.maptools.org>; Wed, 12 Dec 2012 18:42:45 -0500 (EST)
From: Tom Lane <tgl@sss.pgh.pa.us>
To: tiff@lists.maptools.org
Date: Wed, 12 Dec 2012 18:42:45 -0500
Message-ID: <17655.1355355765@sss.pgh.pa.us>
Subject: [Tiff] Dealing with unportability of malloc(0)
X-BeenThere: tiff@lists.maptools.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: TIFF and libtiff discussion <tiff.lists.maptools.org>
List-Unsubscribe: <http://lists.maptools.org/mailman/listinfo/tiff>,
	<mailto:tiff-request@lists.maptools.org?subject=unsubscribe>
List-Archive: <http://lists.maptools.org/mailman/private/tiff>
List-Post: <mailto:tiff@lists.maptools.org>
List-Help: <mailto:tiff-request@lists.maptools.org?subject=help>
List-Subscribe: <http://lists.maptools.org/mailman/listinfo/tiff>,
	<mailto:tiff-request@lists.maptools.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: tiff-bounces@lists.maptools.org
Errors-To: tiff-bounces@lists.maptools.org

I noticed that Bob Friesenhahn recently committed this change to make
_TIFFmalloc() behave the same on platforms where malloc(0) returns a
zero-sized chunk of memory as it does on platforms where the same
call returns NULL:

*** 257,262 ****
--- 257,265 ----
  void*
  _TIFFmalloc(tmsize_t s)
  {
+         if (s == 0)
+                 return ((void *) NULL);
+ 
        return (malloc((size_t) s));
  }
  
I'd like to suggest that this be considered further and perhaps flipped
to the opposite convention, ie, always return an actual block of memory.
That's not hard to accomplish by increasing a request size of 0 to 1
byte:

	if (s == 0)
-		return ((void *) NULL);
+		s = 1;

The reason I think the never-null convention is preferable is that the
null-for-zero convention tends to require doctoring up call sites.
The typical pattern is

	ptr = _TIFFmalloc(some_request);
	if (ptr == NULL)
		// throw error

If there's any possibility that some_request is (validly) zero, this
code is now broken, because it will throw errors when it should not.

Now, libtiff is more fortunate than many projects in that most places
that might have this problem are calling _TIFFCheckMalloc, which means
that there are fewer places to fix than there might be.  But I doubt
that that's really the only one.  In fact, if that *were* the only one,
we'd not need this patch at all, because that call site already tries to
dodge the platform dependency.

... unfortunately, it does so incorrectly.  _TIFFCheckMalloc is coded
to call _TIFFCheckRealloc, and the latter is miswritten so that it is
guaranteed to throw error for a zero request, no matter which behavior
the underlying malloc and realloc calls have.

And, just to add insult to injury, first it will leak the old block
if there is one, since neither realloc() nor free() will get called.

None of this is terribly hard to fix, but first we need a policy
decision about which platform-specific behavior we want to standardize
on.  I gave my argument above, does anyone want to advocate for the
other way?  Are there pieces of libtiff where the null-for-zero
convention is preferable?

			regards, tom lane
_______________________________________________
Tiff mailing list: Tiff@lists.maptools.org
http://lists.maptools.org/mailman/listinfo/tiff
http://www.remotesensing.org/libtiff/
