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 1/3lLCZKLFiLZgAAsyOMew
	for <filtered@awaresystems.be>; Wed, 16 Nov 2016 12:49:31 +0000
X-HalOne-ID: 1e221692-abfb-11e6-92ff-549f350a6292
Received: from mail-oi0-f47.google.com (unknown [209.85.218.47])
	by mx7.public.one.com (Halon Mail Gateway) with ESMTPS
	for <filtered@awaresystems.be>; Wed, 16 Nov 2016 12:49:30 +0000 (UTC)
Received: by mail-oi0-f47.google.com with SMTP id b126so21302003oia.2
        for <filtered@awaresystems.be>; Wed, 16 Nov 2016 04:49:30 -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=2BjJmzOpF1zIHQJDJaEMke1cjgAFcxJYTtu1jyVJ9SU=;
        b=flIT39l1HXV2LhUm5xSELk99ef/E/STyaNyUElbrBY4OeOIqAD/hayBhzW2916oxme
         1prlZ7lxW9eE2eJGMLir1xcvj8bS/lF/3PrJI6NOIENzgkhL3h+tK9W7JaybLvxn+lu4
         3Zw4srGlr5fZbUnZQ28pdZNR49uP/pigm+rAl7NjqfS4kUXXhQN2JNkRTXyxWGHPazcE
         8n9icOo/a5Llcb04WCaxqw5CVAVc6tburGLdsfJsht331hjU5fNdUaP8B879gh2WyKfM
         qn+2rfLkX15QyfOLXEDFdntrAwZfWu2sA1dm/ppEjOGfJJDX/sxCpOpQVOHpBzKEf/hV
         ggVg==
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: ABUngve9oqSeN/3tqryyuKLTq0pkbeOTNo9PR2F8Hl31Sx5YiFkRl3CBGl2BYwzNW5vVENvo8UCsop1isn+wUa5PT80wQeI=
X-Received: by 10.157.50.162 with SMTP id u31mr2043893otb.267.1479300569325;
        Wed, 16 Nov 2016 04:49:29 -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 q129csp192701oif;
        Wed, 16 Nov 2016 04:49:28 -0800 (PST)
X-Received: by 10.28.113.218 with SMTP id d87mr9032794wmi.111.1479300568389;
        Wed, 16 Nov 2016 04:49:28 -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 k83si557219wmk.31.2016.11.16.04.49.27;
        Wed, 16 Nov 2016 04:49:28 -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 3E6A435C03D;
	Wed, 16 Nov 2016 07:48:46 -0500 (EST)
Received: from mail-vk0-f46.google.com (mail-vk0-f46.google.com
	[209.85.213.46])
	by lists.maptools.org (Postfix) with ESMTPS id 6483B35C035
	for <tiff@lists.maptools.org>; Wed, 16 Nov 2016 07:30:18 -0500 (EST)
Received: by mail-vk0-f46.google.com with SMTP id w194so113289630vkw.2
	for <tiff@lists.maptools.org>; Wed, 16 Nov 2016 04:30:18 -0800 (PST)
X-Received: by 10.31.95.210 with SMTP id t201mr1331694vkb.49.1479299417051;
	Wed, 16 Nov 2016 04:30:17 -0800 (PST)
MIME-Version: 1.0
Received: by 10.31.52.196 with HTTP; Wed, 16 Nov 2016 04:29:56 -0800 (PST)
In-Reply-To: <DM5PR12MB1818436388FFC7107C5D1D1084BE0@DM5PR12MB1818.namprd12.prod.outlook.com>
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>
	<CAO=tXLBnLPHUowC3p6jAvgThhEBNX1ngcQFerPDKNc-ruPJySQ@mail.gmail.com>
	<DM5PR12MB1818436388FFC7107C5D1D1084BE0@DM5PR12MB1818.namprd12.prod.outlook.com>
From: Yakov Galka <ybungalobill@gmail.com>
Date: Wed, 16 Nov 2016 14:29:56 +0200
Message-ID: <CAO=tXLBVb8sJSwMM=_vTYGXetnsi7SBXcHDKEBrCVYnKBODnfg@mail.gmail.com>
To: Gerben Vos <Gerben.Vos@zylab.com>
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="===============0259464020=="
Mime-version: 1.0
Sender: tiff-bounces@lists.maptools.org
Errors-To: tiff-bounces@lists.maptools.org

--===============0259464020==
Content-Type: multipart/alternative; boundary=001a114e2b8045190605416a3ca0

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

On Wed, Nov 16, 2016 at 2:04 PM, Gerben Vos <Gerben.Vos@zylab.com> wrote:

> Why is the context named? It smells like magic behavior at a distance
> (even though it doesn't seem to be) that the name of the context and the
> opened tiff are the same.
>

I don't understand your complaints. It is already in the libTIFF API that
you can create a context with one name and use it to read a file of another
name. E.g.:

    TIFFClientOpen("junk", ... functions which read from whatever ...);

... or:

    TIFFFdOpen(open("a.txt"), "b.txt", "r);

It is just a feature of the existing API that the TIFF structure has an
associated name, and this name is used mostly for error reporting.

The term "filename" used currently by the library is actually misleading,
because as with the case of TIFFClientOpen it might correspond to something
that's not really an FS file.

It is also a feature of the existing implementation that this name is
allocated as part of the TIFF structure (in one malloc call), so it has to
be passed as part of TIFF creation rather than set later by a different API
call.


I did a thread-safety analysis a few years ago, but did not contact the
> mailing list about it. My implementation ideas for fixing those were more
> among the lines of those in the patch attached to
> http://bugzilla.maptools.org/show_bug.cgi?id=3D2255 , except that I thoug=
ht
> of calling the context object with the formerly global variables a
> TIFFContext instead of a TIFFApplication. There would then be a default
> context (that would still be the, only, global variable) that would be us=
ed
> by code that didn=E2=80=99t create their own context. I don't have an
> implementation, though.
>
> Here are the main notes from my thread-safety analysis at that time
> (September 2014; I think it was for libtiff 4.0.3):
> * TIFFSetErrorHandler/TIFFSetErrorHandlerExt/TIFFError/TIFFErrorExt:
> TIFFErrorHandlerExt _TIFFerrorHandlerExt; TIFFErrorHandler
> _TIFFerrorHandler;
> * TIFFSetWarningHandler/TIFFSetWarningHandlerExt/TIFFWarning/TIFFWarningE=
xt:
> TIFFErrorHandlerExt _TIFFwarningHandlerExt; TIFFErrorHandler
> _TIFFwarningHandler;
> * TIFFSetTagExtender/TIFFDefaultDirectory: static TIFFExtendProc
> _TIFFextender;
> * TIFFRegisterCODEC/TIFFUnRegisterCODEC: static codec_t*
> registeredCODECS; (linked list)
> * TIFFFindCODEC/TIFFIsCODECConfigured/TIFFGetConfiguredCODECs: static
> codec_t* registeredCODECS; (linked list)
> * TIFFPrintDirectory: static uint16 dotrange[2];
> * oog_encode: static int oog_table[NANGLES]; static int initialized =3D 0=
;
> * PixarLogMakeTables/PixarLogEncode: static float Fltsize; static float
> LogK1, LogK2;
>

I would add a future feature request: custom memory allocator.

Even though it is more logical to put CODECs, extenders, etc into a
separate context that is shared by multiple TIFF structures, I believe that
TIFF-specific callbacks should be part of the TIFF, or receive the TIFF*
that caused the callback as one of their arguments.

My patch addresses only the Error/Warning part of these because it is the
most important part for me at this point in time. (Currently we have an
ugly TLS workaround here, which causes me mental pain every time I
accidentally see it, especially in contrast with other libraries, like
openjpeg, which handle it properly.)

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

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">=
On Wed, Nov 16, 2016 at 2:04 PM, Gerben Vos <span dir=3D"ltr">&lt;<a href=
=3D"mailto:Gerben.Vos@zylab.com" target=3D"_blank">Gerben.Vos@zylab.com</a>=
&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px=
 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Why=
 is the context named? It smells like magic behavior at a distance (even th=
ough it doesn&#39;t seem to be) that the name of the context and the opened=
 tiff are the same.<br></blockquote><div><br></div><div>I don&#39;t underst=
and your complaints. It is already in the libTIFF API that you can create a=
 context with one name and use it to read a file of another name. E.g.:<br>=
<br></div><div>=C2=A0=C2=A0=C2=A0 TIFFClientOpen(&quot;junk&quot;, ... func=
tions which read from whatever ...);<br></div><div><br>... or:<br><br></div=
><div>=C2=A0=C2=A0=C2=A0 TIFFFdOpen(open(&quot;a.txt&quot;), &quot;b.txt&qu=
ot;, &quot;r);<br></div><div>=C2=A0<br></div><div>It is just a feature of t=
he existing API that the TIFF structure has an associated name, and this na=
me is used mostly for error reporting.<br><br></div><div>The term &quot;fil=
ename&quot; used currently by the library is actually misleading, because a=
s with the case of TIFFClientOpen it might correspond to something that&#39=
;s not really an FS file.<br><br></div><div>It is also a feature of the exi=
sting implementation that this name is allocated as part of the TIFF struct=
ure (in one malloc call), so it has to be passed as part of TIFF creation r=
ather than set later by a different API call.<br></div><div><br><br></div><=
blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l=
eft:1px solid rgb(204,204,204);padding-left:1ex">

I did a thread-safety analysis a few years ago, but did not contact the mai=
ling list about it. My implementation ideas for fixing those were more amon=
g the lines of those in the patch attached to <a href=3D"http://bugzilla.ma=
ptools.org/show_bug.cgi?id=3D2255" rel=3D"noreferrer" target=3D"_blank">htt=
p://bugzilla.maptools.org/<wbr>show_bug.cgi?id=3D2255</a> , except that I t=
hought of calling the context object with the formerly global variables a T=
IFFContext instead of a TIFFApplication. There would then be a default cont=
ext (that would still be the, only, global variable) that would be used by =
code that didn=E2=80=99t create their own context. I don&#39;t have an impl=
ementation, though.<br>
<br>
Here are the main notes from my thread-safety analysis at that time (Septem=
ber 2014; I think it was for libtiff 4.0.3):<br>
* TIFFSetErrorHandler/<wbr>TIFFSetErrorHandlerExt/<wbr>TIFFError/TIFFErrorE=
xt: TIFFErrorHandlerExt _TIFFerrorHandlerExt; TIFFErrorHandler _TIFFerrorHa=
ndler;<br>
* TIFFSetWarningHandler/<wbr>TIFFSetWarningHandlerExt/<wbr>TIFFWarning/TIFF=
WarningExt: TIFFErrorHandlerExt _TIFFwarningHandlerExt; TIFFErrorHandler _T=
IFFwarningHandler;<br>
* TIFFSetTagExtender/<wbr>TIFFDefaultDirectory: static TIFFExtendProc _TIFF=
extender;<br>
* TIFFRegisterCODEC/<wbr>TIFFUnRegisterCODEC: static codec_t* registeredCOD=
ECS; (linked list)<br>
* TIFFFindCODEC/<wbr>TIFFIsCODECConfigured/<wbr>TIFFGetConfiguredCODECs: st=
atic codec_t* registeredCODECS; (linked list)<br>
* TIFFPrintDirectory: static uint16 dotrange[2];<br>
* oog_encode: static int oog_table[NANGLES]; static int initialized =3D 0;<=
br>
* PixarLogMakeTables/<wbr>PixarLogEncode: static float Fltsize; static floa=
t LogK1, LogK2;<br></blockquote><div><br></div><div>I would add a future fe=
ature request: custom memory allocator. <br></div><div><br></div><div>Even =
though it is more logical to put CODECs, extenders, etc into a separate con=
text that is shared by multiple TIFF structures, I believe that TIFF-specif=
ic callbacks should be part of the TIFF, or receive the TIFF* that caused t=
he callback as one of their arguments.<br><br></div><div>My patch addresses=
 only the Error/Warning part of these because it is the most important  par=
t for me at this point in time. (Currently we have an ugly TLS=20
workaround here, which causes me mental pain every time I accidentally=20
see it, especially in contrast with other libraries, like openjpeg, which h=
andle it properly.)<br clear=3D"all"></div></div><br>-- <br><div class=3D"g=
mail_signature"><div dir=3D"ltr"><div>Yakov Galka<br><a href=3D"http://stan=
num.co.il/" target=3D"_blank">http://stannum.co.il/</a></div></div></div>
</div></div>

--001a114e2b8045190605416a3ca0--

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