Return-Path: <tiff-bounces@remotesensing.org>
Received: from inmx013.isp.belgacom.be (inmx013.isp.belgacom.be [195.238.2.216])
        by mailst034.isp.belgacom.be (8.12.11/8.12.11/Skynet-MAILSTORE-2.14) with ESMTP id i8H4Kn5O028121
        for <joris.at.lebbeke@skynet.be>; Fri, 17 Sep 2004 06:20:49 +0200
        (envelope-from <tiff-bounces@remotesensing.org>)
Received: from xserve.flids.com (adsl-065-083-169-202.sip.mco.bellsouth.net [65.83.169.202])
        by inmx013.isp.belgacom.be (8.12.11/8.12.11/Skynet-IN-2.32) with ESMTP id i8H4KcWg013675
        for <joris.at.lebbeke@skynet.be>; Fri, 17 Sep 2004 06:20:41 +0200
        (envelope-from <tiff-bounces@remotesensing.org>)
Received: from adsl-065-083-169-202.sip.mco.bellsouth.net (localhost [127.0.0.1])
	by xserve.flids.com (Postfix) with ESMTP
	id B271D2F2D35; Fri, 17 Sep 2004 00:20:21 -0400 (EDT)
X-Original-To: tiff@remotesensing.org
Delivered-To: tiff@remotesensing.org
Received: from scooby.simplesystems.org (scooby.simplesystems.org
	[65.66.246.67])
	by xserve.flids.com (Postfix) with ESMTP id E889A2F2D11
	for <tiff@remotesensing.org>; Fri, 17 Sep 2004 00:20:18 -0400 (EDT)
Received: from blade.simplesystems.org (blade.simplesystems.org [65.66.246.74])
	by scooby.simplesystems.org (8.12.10+Sun/8.12.10) with ESMTP id
	i8H4KE9p000809; Thu, 16 Sep 2004 23:20:14 -0500 (CDT)
Date: Thu, 16 Sep 2004 23:20:14 -0500 (CDT)
From: Bob Friesenhahn <bfriesen@simple.dallas.tx.us>
X-X-Sender: bfriesen@blade.simplesystems.org
To: Chris Cox <ccox@adobe.com>
Subject: Re: [Tiff] BigTIFF Tag Value Count issue
In-Reply-To: <p05210618bd7003f36f75@[153.32.48.223]>
Message-ID: <Pine.SOC.4.60.0409162303330.15634@blade.simplesystems.org>
References: <001c01c49c21$2bf33730$c325c850@dfgrrxsknr4e>
	<Pine.SOC.4.60.0409161905220.15634@blade.simplesystems.org>
	<001401c49c4d$bff536f0$379688d9@dfgrrxsknr4e>
	<Pine.SOC.4.60.0409162021080.15634@blade.simplesystems.org>
	<p05210618bd7003f36f75@[153.32.48.223]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Cc: Tiff mailing list <tiff@remotesensing.org>
X-BeenThere: tiff@remotesensing.org
X-Mailman-Version: 2.1.2
Precedence: list
List-Id: TIFF and libtiff discussion  <tiff.remotesensing.org>
List-Unsubscribe: <http://xserve.flids.com/mailman/listinfo/tiff>,
	<mailto:tiff-request@remotesensing.org?subject=unsubscribe>
List-Archive: <http://xserve.flids.com/pipermail/tiff>
List-Post: <mailto:tiff@remotesensing.org>
List-Help: <mailto:tiff-request@remotesensing.org?subject=help>
List-Subscribe: <http://xserve.flids.com/mailman/listinfo/tiff>,
	<mailto:tiff-request@remotesensing.org?subject=subscribe>
Sender: tiff-bounces@remotesensing.org
Errors-To: tiff-bounces@remotesensing.org
X-UIDL: 68d7a27eeb2f5dc038180127b94f292b

On Thu, 16 Sep 2004, Chris Cox wrote:
>>> Option 0: stick with 4 byte tag count members (alignment, tag data <= 4 
>>> gig,
>>> Frank's choice)
>>> Option 1: make it an 8 byte tag count (no alignment, tag data > 4 gig 
>>> allowed)
>>> Option 2, courtesy of Bob: make it 8 byte tag count, add 4 padding bytes
>>> (alignment, tag data > 4 gig allowed)
>>> 
>>> Can I put you down as an option 2 vote, or were you merely signalling 
>>> the
>>> option?
>> 
>> Sure, there should always be a second option so put me down for option 2. 
>> :-)
>
> Can you think of a situation that needs an 8 byte count?
> Or do you just want the size increased on general principles?

The idea was to consume 8 bytes for alignment purposes but use 4 bytes 
out of those 8 bytes to support the value.  Perhaps I misunderstood 
the problem.  I don't have a strong opinion either way, but do believe 
that the format should be aligned to work well with memory-mapping.

If someone wants to create a tiff-bomb, they can do it just as easily 
with 4GB as they can with 1TB.  In fact, the 4GB attack is more likely 
to cause a problem since the machine is more likely to perform the 
request.

> Do you think that increasing the count to 8 bytes would be a problem in 
> libTIFF?

I don't have the libtiff knowledge to properly answer that.  If the 
availability of a native 64-bit storage type can be assumed (pretty 
safe if 32-bit processors are the new baseline) then it doesn't sound 
like an 8 byte value would be a problem.

Bob
======================================
Bob Friesenhahn
bfriesen@simple.dallas.tx.us
http://www.simplesystems.org/users/bfriesen
_______________________________________________
Tiff mailing list
Tiff@remotesensing.org
http://xserve.flids.com/mailman/listinfo/tiff
