Return-Path: <tiff-bounces@lists.maptools.org>
X-Original-To: info@awaresystems.be
Delivered-To: info@awaresystems.be
Received: from mx-m.b-one.net (mx-m.one.com [91.198.169.60])
	by mail9.b-one.net (Postfix) with ESMTP id 29BBF400125
	for <info@awaresystems.be>; Fri,  6 Feb 2009 12:12:45 +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=6 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-m.b-one.net (Postfix) with ESMTP id EF03B189F60F
	for <info@awaresystems.be>; Fri,  6 Feb 2009 12:12:43 +0100 (CET)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
	by lists.maptools.org (Postfix) with ESMTP id 832261D18B116;
	Fri,  6 Feb 2009 06:12:05 -0500 (EST)
Received: from csmtp3.b-one.net (csmtp3.one.com [195.47.247.213])
	by lists.maptools.org (Postfix) with ESMTP id 739EE1D18B11D
	for <tiff@lists.maptools.org>; Fri,  6 Feb 2009 05:44:37 -0500 (EST)
Received: from awarec74cb3e1c (78-22-7-237.access.telenet.be [78.22.7.237])
	by csmtp3.b-one.net (Postfix) with ESMTP id AB7A92414A09;
	Fri,  6 Feb 2009 11:44:36 +0100 (CET)
Message-ID: <42278D87AFEF4967BEDF2905FA68A6D3@awarec74cb3e1c>
From: "Joris Van Damme \(AWare Systems\)" <info@awaresystems.be>
To: "Frank Warmerdam" <warmerdam@pobox.com>,
	"TIFF mailing list" <tiff@lists.maptools.org>
References: <498B321F.3000300@pobox.com>
Date: Fri, 6 Feb 2009 11:44:31 +0100
MIME-Version: 1.0
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.5512
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579
Subject: Re: [Tiff] assertions, and building with DEBUG/NDEBUG
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

Frank, folks,

This is about http://bugzilla.maptools.org/show_bug.cgi?id=1994. I've 
currently no bugzilla log-in, and/or I forgot about it, so I'll go ahead and 
abuse the mailing list.

As far as I can make out, the bug is due to crapy logic in 
TIFFReadDirectory, in tif_dirread.c. It is not by my hand, but here is my 
humble opinion on it anyway.

The procedure goes about it in different stages.
- In a first stage, the primary tags TIFFTAG_SAMPLESPERPIXEL and 
TIFFTAG_COMPRESSION are read in specific hacky manners. The tags themselves 
are next signalled with an IGNORE flag, disabling further duplicate 
processing in subsequent stages. This stage is a based on tag finding in the 
IFD.
- In a second stage, tags for which there is no know definiton get an 
auto-generated definition auto-merged into the definition list (which is a 
problem all by itself, private unknown tags can have different datatypes in 
different IFDs, and if you hack around that problem there's nothing actually 
left to define, so the proper and correct way would be enabling the library 
to work with tags that simply don't have a known definition at all, but 
that's beside the point here). Also, in this stage some more primary tags 
are read and again they're signalled with an IGNORE flag. This stage is 
based on cycling through the tags, rather then finding specific tags in the 
IFD.
- In a third stage, some more primary tags are read in specific manners, and 
tags that aren't in the list of specially handled ones and that aren't 
flagged IGNORE are read in the generic manner. Again, this stage is based on 
cycling through the tags, rather then finding specific tags in the IFD.

The thing is, since the compression tag is read in the first stage, and 
flagged IGNORE, the hacky second and third stages aren't supposed to have to 
deal with it. Thus, a routine like TIFFFetchNormalTag for example, is never 
called for the compression tag. Only, in this particular buggy file we've 
two TIFFTAG_COMPRESSION tags. The first one is signalled IGNORE when it's 
specifically found in the first stage, but the second one isn't. The second 
and/or third stage then cycle through the tags, and find the compression 
tags that aren't signalled IGNORE, and deal with them in default manners 
intended not ever to deal with the compression tag.

A quick fix would be to have any compression tags ignored in the second and 
third stages, whether or not their IGNORE flag is set. Still, that leaves 
the crappy logic intact and similar problems with other tags are guaranteed 
to arise another day. A more throrough fix would be to extend the preceding 
call to TIFFReadDirectoryCheckOrder near the top of the procedure. 
Currently, it just checks order and emits a warning if tags aren't sorted. I 
propose we replace this with a proper sorting routine that guarantees tags 
are unique. That doesn't completely fix all logic to my taste, but it does 
exclude this exact problem on any tag for all future and requires minimum 
code change. Furthermore, it will continue to work with potential future 
code change where more/less tags might be read in special manners in 
more/less/existing stages. Another potential fix might be to have a local 
array of flags inside TIFFReadDirectly, replacing the functionality that is 
currently in the IGNORE flag, where the array is based on the tag code 
rather then the tag instance such that it works when there's duplicate 
instances. The drawback is the big array, and I feel it's a big kludgy.


Best regards,

Joris 

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