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 13:57 "Re: A bug in libtiff error/warning handling", by Paavo Helde

On 5.07.2017 15:40, Olivier Paquet wrote:
> 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.

This can be made to work if the client library installs and restores the 
handlers each time before/after any call to libTIFF. Yes that's tedious 
but better than the current state. Better fixes would mean API changes, 
like adding error/warning pointers to an enhanced version of 
TIFFClientOpen().

Another hypothetical option would be to gather errors and warnings in 
thread local storage inside libTIFF and provide special API calls for 
retrieving these messages for the last libTIFF call in the current 
thread. This means that there would be no need to install any 
error/warning handlers; the client libraries which are not interested in 
the messages would just not call these routines. The messages would be 
automatically cleared in the start of the next libTIFF API call (in the 
same thread).

This is basically the same what I do in our app when calling libtiff. I 
gather the messages in the handlers (held in thread-local storage BTW 
because I cannot trust the tif_clientdata pointer) and if the libtiff 
call fails I will attach the gathered libtiff messages to my error message.

Paavo