Return-Path: <tiff-bounces@lists.maptools.org>
X-Original-To: info@awaresystems.be
Delivered-To: info@awaresystems.be
Received: from mx-g.b-one.net (mx-g.one.com [91.198.169.54])
	by mail9.b-one.net (Postfix) with ESMTP id E8DB840080A
	for <info@awaresystems.be>; Tue,  2 Mar 2010 17:29:24 +0100 (CET)
Received: by mx-g.b-one.net (Postfix, from userid 106)
	id DDFEE3F698A; Tue,  2 Mar 2010 17:29:24 +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-g.b-one.net (Postfix) with ESMTP id 259E63F698A for
 <info@awaresystems.be>; Tue,  2 Mar 2010 17:29:24 +0100 (CET)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by
 lists.maptools.org (Postfix) with ESMTP id C2FB41D19534B; Tue,  2 Mar 2010
 11:28:36 -0500 (EST)
Received: from mail.mvtec.com (mail.mvtec.com [62.245.183.138]) by
 lists.maptools.org (Postfix) with ESMTPS id B4F6D1D31CF06 for
 <tiff@lists.maptools.org>; Tue,  2 Mar 2010 11:06:00 -0500 (EST)
Received: from localhost (localhost [127.0.0.1]) by mail.mvtec.com
 (8.14.4/8.14.2) with ESMTP id o22G5wfY024912 for <tiff@lists.maptools.org>;
 Tue, 2 Mar 2010 17:05:58 +0100
Received: from mail.mvtec.com ([127.0.0.1]) by localhost (mail.mvtec.com
 [127.0.0.1]) (amavisd-new, port 10024) with LMTP id VHxHT88yUt5E for
 <tiff@lists.maptools.org>; Tue,  2 Mar 2010 17:05:46 +0100 (CET)
Received: from [192.168.32.170] (statler.mvtec [192.168.32.170]) by
 mail.mvtec.com (8.14.4/8.14.2) with ESMTP id o22G5h3Q024845
 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for
 <tiff@lists.maptools.org>; Tue, 2 Mar 2010 17:05:43 +0100
Message-ID: <4B8D3757.8030205@mvtec.com>
Date: Tue, 02 Mar 2010 17:05:43 +0100
From: Eric Doenges <doenges@mvtec.com>
Organization: MVTec Software GmbH
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
MIME-Version: 1.0
To: tiff@lists.maptools.org
References: <4B878218.8@mvtec.com>
 <alpine.GSO.2.01.1002261048300.1592@freddy.simplesystems.org>
 <4B8CC8CF.7040807@mvtec.com> <4B8D1EF5.5060003@sidefx.com>
In-Reply-To: <4B8D1EF5.5060003@sidefx.com>
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="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: tiff-bounces@lists.maptools.org
Errors-To: tiff-bounces@lists.maptools.org

Edward Lam wrote:
> Eric Doenges wrote:
>> 1) Can I simply assume that SSIZE_MAX will be defined in <limits.h>, and
>> that <limits.h> will be available for all platforms that matter to libti=
ff ?
> =

> If Visual Studio has SSIZE_MAX in <limits.h>, then it probably will be. :)
> =

> As for the patch, I alluded earlier (poorly?) that ssize_t is not =

> available on all platforms. Specifically, it's not available on Windows. =

> Despite it's name, tif_unix.c has been known to be used on Windows by =

> people. Looking at the source in some detail now, tmsize_t looks to be =

> the cross-platform signed equivalent to size_t in libtiff. Note also =

> that _tiff{Read,Write}Proc() already tries to carefully ensure that =

> "(size_t)size =3D=3D (tmsize_t)size". Given this, I suspect that your ext=
ra =

> checks with SSIZE_MAX are probably unnecessary?
>
> I've probably missed something but I think the original patch was
> sufficient (EINTR issues notwithstanding) as long as "bytes" was
> declared as a tmsize_t?

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 =3D=3D (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 =3D=3D (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 ?

>> 2) What is the correct response to receiving EINTR (i.e. being
>> interrupted before any data is read/written) ? Should the IO operation
>> simply be retried in _tiffReadProc/_tiffWriteProc, or should the caller
>> handle it ?
> =

> To me, this is a thorny issue. On Windows, signals don't exist so you =

> can't exactly check for EINTR. Two ideas off the top of my head:
> =

> - Continue punting. We've lasted this long without it. :) One rationale =

> is to force users to use SA_RESTART with sigaction. Of course it doesn't =

> help you if you're on one of those systems that don't support this. In =

> which case, the caller needs to revert back to providing their own =

> custom handlers again. Does your particular system support SA_RESTART?

The system in question doesn't have signals or support having system
calls being interrupted, so it's not an issue for us. As far a I'm
concerned, if the libtiff maintainers can live with libtiff not handling
EINTR (as is currently the case), so can I. However, since changing the
error handling code to

...
else if (0 =3D=3D bytes)
{
        if (EINTR =3D=3D errno)
                continue;
	else
		return (tmsize_t)-1;
}
...

would be trivial (and should handle the problem of what to do with EINTR
regardless of wether the underlying system actually supports signals or
not - systems without signals shouldn't return EINTR in the first
place), I wanted to hear what the intended behaviour should be.

> =

> - Wrap the read()/write() calls using the TEMP_FAILURE_RETRY() macro and =

> configure it properly depending on the platform. (See: =

> http://www.gnu.org/s/libc/manual/html_node/Interrupted-Primitives.html#In=
terrupted-Primitives)
> =

> =

> Regards,
> -Edward
> =

> =

With kind regards,
Eric D=F6nges
-- =

Dr. Eric D=F6nges                            doenges@mvtec.com
MVTec Software GmbH | Neherstr. 1 | 81675 M=FCnchen  | Germany
www.mvtec.com | Tel: +49 89 457695-0 | Fax: +49 89 457695-55
Gesch=E4ftsf=FChrer: Dr. Wolfgang Eckstein, Dr. Olaf Munkelt
Amtsgericht M=FCnchen HRB 114695
_______________________________________________
Tiff mailing list: Tiff@lists.maptools.org
http://lists.maptools.org/mailman/listinfo/tiff
http://www.remotesensing.org/libtiff/
