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.04 19:31 "Re: A bug in libtiff error/warning handling", by Paavo Helde

On 4.07.2017 21:38, Bob Friesenhahn wrote:
> On Tue, 4 Jul 2017, Paavo Helde wrote:
>>
>> A proper fix would be to deprecate the global handler variables in 
>> libtiff (which are not thread-safe anyway and will conflict between 
>> different libraries anyway) and store the handler function pointer in 
>> the TIFF structure instead, next to tif_clientdata. This would make 
>> the handler specific to a single client and then I would indeed agree 
>> there would be no need to call more than one handler at any time. I 
>> think it has been agreed earlier that this is something what is 
>> needed, but to get this fixed is obviously much more work.
>
> 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.

Thread-specific handlers would work fine for us. Our software is a large 
C++ app containing a ton of thread-specific data already. In C++ the 
thread local storage is even standardized since C++11 with the special 
|thread_local |storage class specifier, no third-party libraries needed, 
but in C the things might be different.

Paavo