2016.11.11 14:03 "[Tiff] Global variables in LibTIFF", by Paavo Helde

I upgraded LibTIFF to current last stable version 4.0.6 and saw it still relies on global variables. In particular I am concerned about error and warning handlers. From tif_error.c:

TIFFErrorHandlerExt _TIFFerrorHandlerExt = NULL;

TIFFErrorHandlerExt
TIFFSetErrorHandlerExt(TIFFErrorHandlerExt handler)
{
     TIFFErrorHandlerExt prev = _TIFFerrorHandlerExt;
     _TIFFerrorHandlerExt = handler;
     return (prev);
}

In my application which is using LibTIFF directly there are also several third-party libraries which are using LibTIFF internally (gdcm, ITK, libopenjpeg, wxWidgets, etc). Depending on the type of linking (static/shared) and the platform-dependent visibility rules of the symbols the LibTIFF library together with the global static variable may become shared by several libraries. This means that an error handler for a wrong library may get called. A wrong error handler would most probably crash when it tries to interpret the tif->tif_clientdata pointer.

In principle problems with accessing tif->tif_clientdata could be circumvented to some extent by using the older error handler (TIFFSetErrorHandler()) and thread-specific data, but the error could still end up in a wrong place. If all error handlers would take care of calling the previously installed error handler, then it would at least be forwarded to the correct place, but this depends on the client code and for example is not done in wxWidgets.

Even if the client code would always take care to call the previous error handler, this still would not be a 100% reliable solution because TIFFSetErrorHandler() is not multithread-safe and if called from multiple threads in parallel, it may return wrong values.

These problems are all caused by using global variables. Why not just add error and warning handler function pointers to the tiff struct, similar to tif_seekproc et al? The same goes for other global variables (_TIFFextender, ...?)

Sharing of libraries is in principle a good thing and stipulated by open source communities, but currently it seems LibTIFF is working against this goal. I see for example that ITK has taken the trouble of mangling all LibTIFF symbols by some macro chemistry, probably for working around such issues.

Cheers
Paavo