Return-Path: <tiff-bounces@lists.maptools.org>
X-Original-To: info@awaresystems.be
Delivered-To: info@awaresystems.be
Received: from mx-l.b-one.net (mx-l.one.com [91.198.169.59])
	by mail9.b-one.net (Postfix) with ESMTP id 0A87640080A
	for <info@awaresystems.be>; Tue,  2 Mar 2010 20:02:33 +0100 (CET)
Received: by mx-l.b-one.net (Postfix, from userid 106)
	id F253C152DD1C; Tue,  2 Mar 2010 20:02:32 +0100 (CET)
X-Virus-Scanned: by one.com
X-Spam-Score: 0
X-Spam-Level: 
X-Spam-Status: No, score=0 tagged_above=0 required=4 tests=[none]
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.4
Received: from lists.maptools.org (lists.maptools.org [65.39.174.144]) by
 mx-l.b-one.net (Postfix) with ESMTP id 182A0152DD1C for
 <info@awaresystems.be>; Tue,  2 Mar 2010 20:02:31 +0100 (CET)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by
 lists.maptools.org (Postfix) with ESMTP id C5F601D354599; Tue,  2 Mar 2010
 14:01:43 -0500 (EST)
Received: from mail.sidefx.com (mail.sidefx.com [38.99.137.163]) by
 lists.maptools.org (Postfix) with ESMTP id 57A561D18E0DC for
 <tiff@lists.maptools.org>; Tue,  2 Mar 2010 13:13:42 -0500 (EST)
Message-ID: <4B8D5548.9040006@sidefx.com>
Date: Tue, 02 Mar 2010 13:13:28 -0500
From: Edward Lam <edward@sidefx.com>
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
MIME-Version: 1.0
To: Eric Doenges <doenges@mvtec.com>
References: <4B878218.8@mvtec.com>
 <alpine.GSO.2.01.1002261048300.1592@freddy.simplesystems.org>
 <4B8CC8CF.7040807@mvtec.com> <4B8D1EF5.5060003@sidefx.com>
 <4B8D3757.8030205@mvtec.com>
In-Reply-To: <4B8D3757.8030205@mvtec.com>
Cc: tiff@lists.maptools.org
Subject: Re: [Tiff] Patch for tif_unix.c
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: tiff-bounces@lists.maptools.org
Errors-To: tiff-bounces@lists.maptools.org

Eric Doenges wrote:
> If tmsize_t can be guaranteed to be identical to ssize_t, then no check
> is necessary (as long as we can assume there are no systems where
> SSIZE_MAX is smaller than what would physically fit into a ssize_t). If
> not, then the "(size_t)size == (tmsize_t)size" check won't necessarily
> help us as the read()/write() functions have undefined behaviour when
> attempting to read/write more than SSIZE_MAX bytes.
> 
> However, if tmsize_t is just a libtiff equivalent to ssize_t, then the
> "(size_t)size == (tmsize_t)size" isn't necessary either, since the
> condition should always be true (unless a negative size is requested,
> which doesn't make any sense for I/O operations). I had assumed the
> check was necessary because tmsize_t might be bigger than {s}size_t, and
> thus didn't think I could use tmsize_t instead of ssize_t. Perhaps
> whoever wrote the current form of the _tiff{Read,Write}Proc() functions
> could chime in as to what was intended ?

If tmsize_t was bigger than ssize_t, then woudn't we already have a bug 
in the original code? In practice, coding errors could potentially cause 
us to get negative size values so this could be just defensive coding?

Bob Friesenhahn committed revision 1.18 of tif_unix.c where we used to 
have a loop that ensured that we never wrong more than SSIZE_MAX bytes 
at a time. So, Bob? :)

Regards,
-Edward
_______________________________________________
Tiff mailing list: Tiff@lists.maptools.org
http://lists.maptools.org/mailman/listinfo/tiff
http://www.remotesensing.org/libtiff/
