2017.05.21 19:28 "[Tiff] Libtiff 4.0.8 released", by Bob Friesenhahn

2017.07.05 12:40 "Re: [Tiff] 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