Return-Path: <tiff-bounces@lists.maptools.org>
Delivered-To: info@awaresystems.be
Received: (qmail 26903 invoked from network); 23 Aug 2008 16:53:28 -0000
Received: from judy.telenet-ops.be ([195.130.136.7])
          (envelope-sender <tiff-bounces@lists.maptools.org>)
          by angelia.telenet-ops.be (qmail-ldap-1.03) with SMTP
          for <info@awaresystems.be>; 23 Aug 2008 16:53:28 -0000
Received: from mindy.telenet-ops.be (mindy.telenet-ops.be [195.130.136.8])
	by judy.telenet-ops.be (8.13.1/8.13.1) with ESMTP id m7NGrSdn010850
	for <info@awaresystems.be>; Sat, 23 Aug 2008 18:53:28 +0200
Received: from localhost (localhost.localdomain [127.0.0.1])
	by mindy.telenet-ops.be (Postfix) with SMTP id 2357B60005
	for <info@awaresystems.be>; Sat, 23 Aug 2008 18:53:28 +0200 (CEST)
Received: from apate.telenet-ops.be (apate.telenet-ops.be [195.130.132.43])
	by mindy.telenet-ops.be (Postfix) with ESMTP id D934A60004
	for <info@awaresystems.be>; Sat, 23 Aug 2008 18:53:27 +0200 (CEST)
Received: from duke.maptools.org (r153.dmsolutions.ca [209.217.116.153])
	by apate.telenet-ops.be (Postfix) with ESMTP id 6CBCC27EC02
	for <info@awaresystems.be>; Sat, 23 Aug 2008 18:53:27 +0200 (CEST)
Received: from duke.maptools.org (duke.maptools.org [127.0.0.1])
	by duke.maptools.org (8.12.11/8.12.10) with ESMTP id m7NGpOnN026607;
	Sat, 23 Aug 2008 12:52:42 -0400
Received: from cans01.commander-aero.com (cans01.commander-aero.com
	[69.61.160.67])
	by duke.maptools.org (8.12.11/8.12.10) with ESMTP id m7NGpKwT026604
	for <tiff@lists.maptools.org>; Sat, 23 Aug 2008 12:51:21 -0400
Received: from localhost (localhost [127.0.0.1])
	by cans01.commander-aero.com (Postfix) with ESMTP id CB2F11A966;
	Sat, 23 Aug 2008 12:48:36 -0400 (EDT)
Received: from cans01.commander-aero.com ([127.0.0.1])
	by localhost (cans01.commander-aero.com [127.0.0.1]) (amavisd-new,
	port 10024)
	with ESMTP id 27758-01; Sat, 23 Aug 2008 12:48:36 -0400 (EDT)
Received: from [192.168.1.103] (65-86-65-110.client.dsl.net [65.86.65.110])
	by cans01.commander-aero.com (Postfix) with ESMTP id 5CAE319BC0;
	Sat, 23 Aug 2008 12:48:35 -0400 (EDT)
Subject: Re: [Tiff] creating sparse files......
From: Gene Amtower <gene@pc-backup.com>
To: Rogier Wolff <R.E.Wolff@bitwizard.nl>
In-Reply-To: <20080823155854.GA28115@bitwizard.nl>
References: <20080822085634.GA21294@bitwizard.nl>
	<Pine.SOC.4.64.0808220936280.1110@freddy.simplesystems.org>
	<20080822162748.GB29030@bitwizard.nl>
	<Pine.SOC.4.64.0808221131320.1110@freddy.simplesystems.org>
	<20080822165232.GE29030@bitwizard.nl>
	<Pine.SOC.4.64.0808221249090.1110@freddy.simplesystems.org>
	<20080823150831.GE18815@bitwizard.nl>
	<Pine.SOC.4.64.0808231051400.1110@freddy.simplesystems.org>
	<20080823155854.GA28115@bitwizard.nl>
Organization: PC Backup
Date: Sat, 23 Aug 2008 12:51:17 -0400
Message-Id: <1219510277.4308.258.camel@PCB-Bench-01>
Mime-Version: 1.0
X-Mailer: Evolution 2.0.4 (2.0.4-7) 
X-Virus-Scanned: amavisd-new at commander-aero.com
Cc: tiff@lists.maptools.org
X-BeenThere: tiff@lists.maptools.org
X-Mailman-Version: 2.1.4
Precedence: list
Reply-To: gene@pc-backup.com
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: multipart/mixed; boundary="===============0364301704=="
Sender: tiff-bounces@lists.maptools.org
Errors-To: tiff-bounces@lists.maptools.org
X-SpamCatcher-Score: 2 [X]


--===============0364301704==
Content-Type: multipart/alternative; boundary="=-6TAt5D71BwCkT/TE+rTr"


--=-6TAt5D71BwCkT/TE+rTr
Content-Type: text/plain
Content-Transfer-Encoding: 7bit

On Sat, 2008-08-23 at 17:58 +0200, Rogier Wolff wrote:

> There are standards that imply the answer "8" from the
> short program above, and correct results from the code I suggested.


As I lurk through this string of posts, I wonder if there's an
underlying concern that's not overtly stated in these discussions.
Since the libtiff library is so widely used, is there a general concern
with the completeness or correctness of the POSIX standard itself, or is
there concern with how thoroughly the POSIX standard is implemented on
the wide variety of platforms that libtiff will encounter?  Are the
issues centered on the various ways the libtiff library can be compiled,
even with a single platform?  On the other hand, are the concerns with
simply hashing out the potential issues and insuring that the library
considers all potential effects of this suggested code?  I wonder if a
more formal summary of the platforms involved and the pros and cons of
each would help the discussion - does that happen somewhere in the open-
source development model of libtiff and similar projects, maybe
somewhere below the surface of this discussion list?

I'm not well-versed in the POSIX standard myself, but my thoughts are
focused on understanding the source of the concerns stated, and driving
towards a summary of the effects and issues.  It sounds like this
discussion has various strong opinions, so I just wanted to help with a
focus on clarification.  Hope it contributes to the discussion.

Kindly,

   Gene

--=-6TAt5D71BwCkT/TE+rTr
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 7bit

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
  <META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
  <META NAME="GENERATOR" CONTENT="GtkHTML/3.3.2">
</HEAD>
<BODY>
On Sat, 2008-08-23 at 17:58 +0200, Rogier Wolff wrote:<BR>
<BLOCKQUOTE TYPE=CITE>
    <TT><FONT COLOR="#000000">There are standards that imply the answer &quot;8&quot; from the</FONT></TT><BR>
    <TT><FONT COLOR="#000000">short program above, and correct results from the code I suggested.</FONT></TT><BR>
</BLOCKQUOTE>
<BR>
As I lurk through this string of posts, I wonder if there's an underlying concern that's not overtly stated in these discussions.&nbsp; Since the libtiff library is so widely used, is there a general concern with the completeness or correctness of the POSIX standard itself, or is there concern with how thoroughly the POSIX standard is implemented on the wide variety of platforms that libtiff will encounter?&nbsp; Are the issues centered on the various ways the libtiff library can be compiled, even with a single platform?&nbsp; On the other hand, are the concerns with simply hashing out the potential issues and insuring that the library considers all potential effects of this suggested code?&nbsp; I wonder if a more formal summary of the platforms involved and the pros and cons of each would help the discussion - does that happen somewhere in the open-source development model of libtiff and similar projects, maybe somewhere below the surface of this discussion list?<BR>
<BR>
I'm not well-versed in the POSIX standard myself, but my thoughts are focused on understanding the source of the concerns stated, and driving towards a summary of the effects and issues.&nbsp; It sounds like this discussion has various strong opinions, so I just wanted to help with a focus on clarification.&nbsp; Hope it contributes to the discussion.<BR>
<BR>
Kindly,<BR>
<BR>
&nbsp;&nbsp; Gene
</BODY>
</HTML>

--=-6TAt5D71BwCkT/TE+rTr--


--===============0364301704==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Tiff mailing list: Tiff@lists.maptools.org
http://lists.maptools.org/mailman/listinfo/tiff
http://www.remotesensing.org/libtiff/
--===============0364301704==--

