Return-Path: <tiff-bounces@lists.maptools.org>
Received: from inas012.isp.belgacom.be (localhost [127.0.0.1])
        by inav020.isp.belgacom.be (8.12.11/8.12.11/Skynet-IN-AV-3.00) with ESMTP id k033he0B023807
        for <joris.at.lebbeke@skynet.be>; Tue, 3 Jan 2006 04:43:41 +0100
        (envelope-from <tiff-bounces@lists.maptools.org>)
Received: from inmx005.isp.belgacom.be (inmx005.isp.belgacom.be [195.238.5.148])
        by inas012.isp.belgacom.be (8.12.11/8.12.11/Skynet-IN-AS-2.03) with ESMTP id k033hbx2002219
        for <joris.at.lebbeke@skynet.be>; Tue, 3 Jan 2006 04:43:38 +0100
        (envelope-from <tiff-bounces@lists.maptools.org>)
Received: from duke.maptools.org (r153.dmsolutions.ca [209.217.116.153] (may be forged))
        by inmx005.isp.belgacom.be (8.12.11/8.12.11/Skynet-IN-2.32) with ESMTP id k033hZYb010071
        for <joris.at.lebbeke@skynet.be>; Tue, 3 Jan 2006 04:43:36 +0100
        (envelope-from <tiff-bounces@lists.maptools.org>)
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 k030TssC030761;
	Mon, 2 Jan 2006 19:31:17 -0500
Received: from eastrmmtao02.cox.net (eastrmmtao02.cox.net [68.230.240.37])
	by duke.maptools.org (8.12.11/8.12.10) with ESMTP id k030S008030758
	for <tiff@lists.maptools.org>; Mon, 2 Jan 2006 19:28:00 -0500
Received: from glerbl ([70.174.166.65]) by eastrmmtao02.cox.net
	(InterMail vM.6.01.05.02 201-2131-123-102-20050715) with ESMTP
	id <20060103002608.HQFB14821.eastrmmtao02.cox.net@glerbl>
	for <tiff@lists.maptools.org>; Mon, 2 Jan 2006 19:26:08 -0500
Received: from soup ([10.160.59.17]) by glerbl with esmtp (Exim 4.50)
	id 1Eta1t-0006V5-LO
	for tiff@lists.maptools.org; Mon, 02 Jan 2006 19:27:57 -0500
Received: from ejb by soup with local (Exim 4.60) (envelope-from <ejb@ql.org>)
	id 1Eta1t-000428-Kr; Mon, 02 Jan 2006 19:27:57 -0500
From: Jay Berkenbilt <ejb@ql.org>
To: Tiff List <tiff@lists.maptools.org>
Subject: Re: [Tiff] Outrageous profile tag sizes reported by libtiff 3.8.0
References: <Pine.SOC.4.60.0601011041320.4804@blade.simplesystems.org>
	<Pine.SOC.4.60.0601011137160.4804@blade.simplesystems.org>
	<Pine.SOC.4.60.0601011240590.4804@blade.simplesystems.org>
	<Pine.SOC.4.60.0601011453380.4804@blade.simplesystems.org>
	<Pine.SOC.4.60.0601020957350.4804@blade.simplesystems.org>
Message-ID: <20060102192757.0616925048.qww314159@soup.q.ql.org>
Date: Mon, 02 Jan 2006 19:27:57 -0500
In-Reply-To: <Pine.SOC.4.60.0601020957350.4804@blade.simplesystems.org> (Bob
	Friesenhahn's message of "Mon, 2 Jan 2006 10:08:21 -0600 (CST)")
User-Agent: Gnus/5.110004 (No Gnus v0.4) Emacs/22.0.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-BeenThere: tiff@lists.maptools.org
X-Mailman-Version: 2.1.4
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>
Sender: tiff-bounces@lists.maptools.org
Errors-To: tiff-bounces@lists.maptools.org
X-UIDL: 000000000023ceae.000010ae
X-MSP-STORE: Tue, 03 Jan 2006 04:43:45 +0100
Status:   

Bob Friesenhahn <bfriesen@simple.dallas.tx.us> wrote:

> A bit of testing shows that previously the third parameter of
> TIFFGetField() was of type uint32 when retrieving TIFFTAG_ICCPROFILE,
> TIFFTAG_PHOTOSHOP, TIFFTAG_RICHTIFFIPTC, TIFFTAG_XMLPACKET, but in
> 3.8.0 the size is a uint16.  Unfortunately this interface is not fully
> defined by a header file since it is based on a variable argument
> list.  Libtiff 3.8.0 is *not* binary compatible with previous
> releases.
>
> The TIFFGetField() documentation does not address these tags.

For such a small change, I would vote for reverting it rather than
introducing a binary incompatibility.  Library ABI changes are a big
deal for distributions, so it would be shame to have to have one for
such a small change.  I doubt many debian applications or libraries
use these tags, but it's certainly possible that some do and likely
that some debian users use them in their own programs.  I was hoping
that the next ABI change would coincide with a library with release
that used full symbol versioning and took advantage of one big chance
to break everything that needs breaking all at once.

Is there a chance that this change will be reverted, or are we stuck
with it?

-- 
Jay Berkenbilt <ejb@ql.org>
_______________________________________________
Tiff mailing list: Tiff@lists.maptools.org
http://lists.maptools.org/mailman/listinfo/tiff
http://www.remotesensing.org/libtiff/
