AWARE [SYSTEMS] Imaging expertise for the Delphi developer
AWare Systems, Imaging expertise for the Delphi developer, Home TIFF and LibTiff Mailing List Archive

LibTiff Mailing List

TIFF and LibTiff Mailing List Archive
July 2017

Previous Thread
Next Thread

Previous by Thread
Next by Thread

Previous by Date
Next by Date

Contact

The TIFF Mailing List Homepage
This list is run by Frank Warmerdam
Archive maintained by AWare Systems



Valid HTML 4.01!



Thread

2017.07.04 11:04 "A bug in libtiff error/warning handling", by Paavo Helde
2017.07.04 11:30 "Re: A bug in libtiff error/warning handling", by Even Rouault
2017.07.04 12:20 "Re: A bug in libtiff error/warning handling", by <rleigh@codelibre.net>
2017.07.04 12:55 "Re: A bug in libtiff error/warning handling", by Even Rouault
2017.07.04 12:30 "Re: A bug in libtiff error/warning handling", by Paavo Helde
2017.07.04 18:38 "Re: A bug in libtiff error/warning handling", by Bob Friesenhahn
2017.07.04 19:31 "Re: A bug in libtiff error/warning handling", by Paavo Helde
2017.07.05 12:12 "Re: A bug in libtiff error/warning handling", by Edward Lam
2017.07.05 12:40 "Re: A bug in libtiff error/warning handling", by Olivier Paquet
2017.07.05 13:41 "Re: A bug in libtiff error/warning handling", by Bob Friesenhahn
2017.07.05 13:57 "Re: A bug in libtiff error/warning handling", by Paavo Helde
2017.07.05 15:02 "Re: A bug in libtiff error/warning handling", by Olivier Paquet
2017.07.05 18:51 "Re: A bug in libtiff error/warning handling", by Paavo Helde
2017.07.05 19:36 "Re: A bug in libtiff error/warning handling", by Olivier Paquet

2017.07.05 12:40 "Re: A bug in libtiff error/warning handling", by Olivier Paquet

2017-07-05 8:12 GMT-04:00 Edward Lam <edward@sidefx.com>:
> On 7/4/2017 2:38 PM, Bob Friesenhahn wrote:
>> This would not work for the common case of reporting an error when
>> there is no TIFF handle.  There would need to be additional parameters
>> added for the functions which open a a TIFF.
>>
>> If OS thread APIs can be used, then there is the option to use thread
>> specific data without any API change, but a possible added library
>> dependency.
>
> Just thinking out loud here. If there was some way to get the client code to
> provide a callback that returned a thread specific id, then libtiff could use

And where do you store that callback? You're going round in circles here :-)

By the way, thread local storage is a poor solution as it does not
handle the case of several unrelated libraries using libtiff from
within the same thread. Giving TIFFOpen and a few other functions
which run without a TIFF handle the error handler is the proper way to
fix this problem. Either that or come with with a concept of "library
handle" which would do the same with more indirection and flexibility.
Perhaps it's time to design a new version of TIFFOpen as I'm fairly
certain I remember other issues with it. Or perhaps that was
TIFFClientOpen and windows handles.

Olivier