Return-Path: <awaresystems.be+caf_=filtered=awaresystems.be@gmail.com>
Delivered-To: filtered@awaresystems.be
Received: from mx7.public.one.com ([10.246.18.27])
	by mail6.local.one.com (Dovecot) with LMTP id 2uMLJOE9J1jEwQAAsyOMew
	for <filtered@awaresystems.be>; Sat, 12 Nov 2016 16:09:45 +0000
X-HalOne-ID: 6d559ebd-a8f2-11e6-92ff-549f350a6292
Received: from mail-oi0-f53.google.com (unknown [209.85.218.53])
	by mx7.public.one.com (Halon Mail Gateway) with ESMTPS
	for <filtered@awaresystems.be>; Sat, 12 Nov 2016 16:09:44 +0000 (UTC)
Received: by mail-oi0-f53.google.com with SMTP id v84so16798902oie.3
        for <filtered@awaresystems.be>; Sat, 12 Nov 2016 08:09:44 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20130820;
        h=x-original-authentication-results:x-gm-message-state:delivered-to
         :mime-version:in-reply-to:references:from:date:message-id:to:cc
         :subject:precedence:list-id:list-unsubscribe:list-archive:list-post
         :list-help:list-subscribe:mime-version:sender:errors-to;
        bh=Qk0ui21Tp0SIpr5q/ekKo7q/LFV8aw1at6dcRTSoPkE=;
        b=X2rFYC8OjBHshCpvGhMYw3xqfERYEgSNM4lzd7M6AvG/T1WBqNh0Fye16qd6Jf+wG7
         dMsT4MXwUZy6LlSw68Zpaa5jPpoZey0B17t9Uv7aZr8S/I1n9gH38LWhP2Rr53oaq/o+
         I25qim3tcgKMO3VNxC8/CGlgDChR7UF67Oag14i/Im2d6DV2pZ28Pw6ivFA5Y4PYcLtB
         qU80xnoI7S4GBoQKIm9MQC5eJmFU28AKllCJ/qrTM81MeYuDyqVHWMfy6C/uKUBHVCcF
         BgIvncJBWfF9vZsHKDgZANkNDylaoaMiURvCfxDFEwjbNd4Ub1Zpp/5pLuKKpLwZsXxy
         BmDg==
X-Original-Authentication-Results: mx.google.com;       spf=neutral (google.com: 94.23.4.142 is neither permitted nor denied by best guess record for domain of tiff-bounces@lists.maptools.org) smtp.mailfrom=tiff-bounces@lists.maptools.org;       dmarc=fail (p=NONE dis=NONE) header.from=gmail.com
X-Gm-Message-State: ABUngvcEPoZtDFbPvfl37JpvIveOzb4DTGCCnzyi6sbRUKHPaAdY2tMNDvGbGRIQupkXhHPt2szUfkbjfveu38MmHlXydqI=
X-Received: by 10.157.41.9 with SMTP id d9mr3474112otb.69.1478966983119;
        Sat, 12 Nov 2016 08:09:43 -0800 (PST)
X-Forwarded-To: filtered@awaresystems.be
X-Forwarded-For: awaresystems.be@gmail.com filtered@awaresystems.be
Delivered-To: awaresystems.be@gmail.com
Received: by 10.202.192.135 with SMTP id q129csp303078oif;
        Sat, 12 Nov 2016 08:09:42 -0800 (PST)
X-Received: by 10.28.49.3 with SMTP id x3mr3063446wmx.121.1478966981951;
        Sat, 12 Nov 2016 08:09:41 -0800 (PST)
Return-Path: <tiff-bounces@lists.maptools.org>
Received: from lists.maptools.org (ks365428.kimsufi.com. [94.23.4.142])
        by mx.google.com with ESMTP id hp1si16067529wjb.225.2016.11.12.08.09.41;
        Sat, 12 Nov 2016 08:09:41 -0800 (PST)
Received-SPF: neutral (google.com: 94.23.4.142 is neither permitted nor denied by best guess record for domain of tiff-bounces@lists.maptools.org) client-ip=94.23.4.142;
Authentication-Results: mx.google.com;
       spf=neutral (google.com: 94.23.4.142 is neither permitted nor denied by best guess record for domain of tiff-bounces@lists.maptools.org) smtp.mailfrom=tiff-bounces@lists.maptools.org;
       dmarc=fail (p=NONE dis=NONE) header.from=gmail.com
Received: from [10.1.0.241] (localhost.localdomain [127.0.0.1])
	by lists.maptools.org (Postfix) with ESMTP id 3DA8535C06F;
	Sat, 12 Nov 2016 11:08:55 -0500 (EST)
Received: from mail-ua0-f169.google.com (mail-ua0-f169.google.com
	[209.85.217.169])
	by lists.maptools.org (Postfix) with ESMTPS id AAD0A35C06D
	for <tiff@lists.maptools.org>; Sat, 12 Nov 2016 11:04:58 -0500 (EST)
Received: by mail-ua0-f169.google.com with SMTP id 12so34949098uas.2
	for <tiff@lists.maptools.org>; Sat, 12 Nov 2016 08:04:58 -0800 (PST)
X-Received: by 10.176.68.132 with SMTP id n4mr5092037uan.75.1478966697050;
	Sat, 12 Nov 2016 08:04:57 -0800 (PST)
MIME-Version: 1.0
Received: by 10.31.52.196 with HTTP; Sat, 12 Nov 2016 08:04:36 -0800 (PST)
In-Reply-To: <alpine.GSO.2.20.1611120843380.23214@freddy.simplesystems.org>
References: <5825CFAD.7010103@osa.pri.ee>
	<CAAcuQeb5QHkamv35Fk9OELBUkwBpHigt9kLOFqvhezj06XGnpg@mail.gmail.com>
	<201611112232.47557.even.rouault@spatialys.com>
	<alpine.GSO.2.20.1611111620130.24281@freddy.simplesystems.org>
	<CAO=tXLDiofTutDdoGf8TJGi_F8V5siJSQBt3w9uYHfrPMTRRQQ@mail.gmail.com>
	<alpine.GSO.2.20.1611120843380.23214@freddy.simplesystems.org>
From: Yakov Galka <ybungalobill@gmail.com>
Date: Sat, 12 Nov 2016 18:04:36 +0200
Message-ID: <CAO=tXLBnLPHUowC3p6jAvgThhEBNX1ngcQFerPDKNc-ruPJySQ@mail.gmail.com>
To: Bob Friesenhahn <bfriesen@simple.dallas.tx.us>
Cc: TIFF mailing list <tiff@lists.maptools.org>
Subject: Re: [Tiff] Global variables in LibTIFF
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: multipart/mixed; boundary="===============0707794063=="
Mime-version: 1.0
Sender: tiff-bounces@lists.maptools.org
Errors-To: tiff-bounces@lists.maptools.org

--===============0707794063==
Content-Type: multipart/alternative; boundary=001a1148c9cc9cc80705411cc473

--001a1148c9cc9cc80705411cc473
Content-Type: text/plain; charset=UTF-8

On Sat, Nov 12, 2016 at 4:56 PM, Bob Friesenhahn <
bfriesen@simple.dallas.tx.us> wrote:

> You must be referring to this statement by Edward Lam (not by me):
>

Oh, sorry about that, I don't really remember :)



> We need to take care that libtiff API improvements don't break the ABI
> since existing users are depending on libtiff releases (when they occur) to
> fix libtiff security issues and bugs without needing to rebuild the
> "world", and (particularly) without needing to patch packages using libtiff
> so that they work again.
>
> API improvements should be layered on top of, or adjacent to, the existing
> API, acting as alternatives without breaking the existing API/ABI.  Changes
> made for libtiff 4.X (e.g. hiding implementation structures) make this
> possible whereas before it was clearly impossible.
>
> Libtiff is 28 years old already and we can not afford to upset the
> substantial body of existing software.


This is all obvious, and if you looked at my patches you've seen that I
introduced the new functionality without breaking the current ABI. The
problems I'm talking about is the (undocumented) API *behavior* wrt the
interplay of some of the library features.

For example:

    int fd = ...;
    TIFF *tiff0 = TIFFOpen("0.tiff", "r");
    TIFFSetClientdata(tiff0, thandle_t(fd));
    TIFFRead(...); // <<<<<<<<<<<<<< This fails on today's libTIFF!

Another example:

    TIFF *tiff0 = TIFFOpen("0.tiff", "r");
    int fd = open("1.tiff", O_RDONLY);
    TIFF *tiff1 = TIFFClientOpen("1.tiff", "r", thandle_t(fd),
        TIFFGetReadProc(tiff0), TIFFGetWriteProc(tiff0),
        TIFFGetSeekProc(tiff0), TIFFGetCloseProc(tiff0),
        TIFFGetSizeProc(tiff0), TIFFGetMapFileProc(tiff0),
        TIFFGetUnmapFileProc(tiff0)
    ); // <<<<<<<<<<<<<<<<<<<<<<<<< Should this work?


Specifically, current libTIFF has the following problems (relevant to this
discussion):

* The built-in i/o procedures use tif_clientdata for recovering the
file-descriptor.
    * Users want to store arbitrary clientdata that will be passed to their
callbacks.
    * Users want to use the error callbacks without reimplementing their
own i/o functions.
    => We need to either free-up tif_clientdata for their exclusive use or
to introduce tif_clientdataV2.
    ! Note that we already have tif_fd, though it's useless on Windows!

* i/o callbacks receive a thandle_t rather than the TIFF* structure.
    => Users implementing i/o callbacks cannot access the properties of the
TIFF*, like mode or filename for the purpose of error reporting.

Both examples above will work without recompilation with my patch. However,
now users will be able to use the new interface as follows:

    TIFF *tiff = TIFFCreateNamedContext("0.tiff");
    TIFFSetClientdata(tiff, my_error_log_pointer);
    TIFFSetSetErrorProcs(tiff, my_error_proc, my_warning_proc);
    _TIFFOpen(tiff, "0.tiff", "r"); // should be TIFFOpenV2

-- 
Yakov Galka
http://stannum.co.il/

--001a1148c9cc9cc80705411cc473
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On S=
at, Nov 12, 2016 at 4:56 PM, Bob Friesenhahn <span dir=3D"ltr">&lt;<a href=
=3D"mailto:bfriesen@simple.dallas.tx.us" target=3D"_blank">bfriesen@simple.=
dallas.tx.us</a>&gt;</span> wrote:<span></span><br><span></span><blockquote=
 class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px so=
lid rgb(204,204,204);padding-left:1ex">
You must be referring to this statement by Edward Lam (not by me):<br></blo=
ckquote><div><br></div><div>Oh, sorry about that, I don&#39;t really rememb=
er :)<br><br>=C2=A0<br></div><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1=
ex">We need to take care that libtiff API improvements don&#39;t break the =
ABI since existing users are depending on libtiff releases (when they occur=
) to fix libtiff security issues and bugs without needing to rebuild the &q=
uot;world&quot;, and (particularly) without needing to patch packages using=
 libtiff so that they work again.<br>
<br>
API improvements should be layered on top of, or adjacent to, the existing =
API, acting as alternatives without breaking the existing API/ABI.=C2=A0 Ch=
anges made for libtiff 4.X (e.g. hiding implementation structures) make thi=
s possible whereas before it was clearly impossible.<br>
<br>
Libtiff is 28 years old already and we can not afford to upset the substant=
ial body of existing software.</blockquote><div><br></div><div>This is all =
obvious, and if you looked at my patches you&#39;ve seen that I introduced =
the new functionality without breaking the current ABI. The problems I&#39;=
m talking about is the (undocumented) API *behavior* wrt the interplay of s=
ome of the library features.<br><br>For example:<br><br></div><div></div><d=
iv>=C2=A0=C2=A0=C2=A0 int fd =3D ...;<br></div><div>=C2=A0=C2=A0=C2=A0 TIFF=
 *tiff0 =3D TIFFOpen(&quot;0.tiff&quot;, &quot;r&quot;);<br>=C2=A0=C2=A0=C2=
=A0 TIFFSetClientdata(tiff0, thandle_t(fd));<br></div><div>=C2=A0=C2=A0=C2=
=A0 TIFFRead(...); // &lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&=
lt; This fails on today&#39;s libTIFF!<br><br></div><div>Another example:<b=
r><br></div>=C2=A0=C2=A0=C2=A0 TIFF *tiff0 =3D TIFFOpen(&quot;0.tiff&quot;,=
 &quot;r&quot;);<br><div><div>=C2=A0=C2=A0=C2=A0 int fd =3D open(&quot;1.ti=
ff&quot;, O_RDONLY);<br></div><div>=C2=A0=C2=A0=C2=A0 TIFF *tiff1 =3D TIFFC=
lientOpen(&quot;1.tiff&quot;, &quot;r&quot;, thandle_t(fd),<br>=C2=A0 =C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0 TIFFGetReadProc(tiff0), TIFFGetWriteProc(tiff0)=
,<br></div><div>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 TIFFGetSeekProc(=
tiff0), TIFFGetCloseProc(tiff0),<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 TIFFGetSize=
Proc(tiff0), TIFFGetMapFileProc(tiff0),<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 TIFF=
GetUnmapFileProc(tiff0)<br></div><div>=C2=A0=C2=A0=C2=A0 ); // &lt;&lt;&lt;=
&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt=
;&lt;&lt;&lt; Should this work?<br></div><br><br>Specifically, current libT=
IFF has the following problems (relevant to this discussion):<br><br></div>=
<div>* The built-in i/o procedures use tif_clientdata for recovering the fi=
le-descriptor.<br></div><div>=C2=A0=C2=A0=C2=A0 * Users want to store arbit=
rary clientdata that will be passed to their callbacks.<br></div><div>=C2=
=A0=C2=A0=C2=A0 * Users want to use the error callbacks without reimplement=
ing their own i/o functions.<br></div><div>=C2=A0=C2=A0=C2=A0 =3D&gt; We ne=
ed to either free-up tif_clientdata for their exclusive use or to introduce=
 tif_clientdataV2.<br></div><div>=C2=A0=C2=A0=C2=A0 ! Note that we already =
have tif_fd, though it&#39;s useless on Windows!<br></div><div><br></div><d=
iv>* i/o callbacks receive a thandle_t rather than the TIFF* structure.<br>=
</div><div>=C2=A0=C2=A0=C2=A0 =3D&gt; Users implementing i/o callbacks cann=
ot access the properties of the TIFF*, like mode or filename for the purpos=
e of error reporting.<br><br></div><div>Both examples above will work witho=
ut recompilation with my patch. However, now users will be able to use the =
new interface as follows:<br><br></div><div>=C2=A0=C2=A0=C2=A0 TIFF *tiff =
=3D TIFFCreateNamedContext(&quot;0.tiff&quot;);<br></div><div>=C2=A0=C2=A0=
=C2=A0 TIFFSetClientdata(tiff, my_error_log_pointer);<br></div><div>=C2=A0=
=C2=A0=C2=A0 TIFFSetSetErrorProcs(tiff, my_error_proc, my_warning_proc);<br=
></div><div>=C2=A0=C2=A0=C2=A0 _TIFFOpen(tiff, &quot;0.tiff&quot;, &quot;r&=
quot;); // should be TIFFOpenV2<br></div><br></div>-- <br><div class=3D"gma=
il-m_858664695744910084gmail_signature"><div dir=3D"ltr"><div>Yakov Galka<b=
r><a href=3D"http://stannum.co.il/" target=3D"_blank">http://stannum.co.il/=
</a></div></div></div>
</div></div>

--001a1148c9cc9cc80705411cc473--

--===============0707794063==
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/
--===============0707794063==--
