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 12:55 "Re: A bug in libtiff error/warning handling", by Even Rouault

> Why can't Handler delegate to HandlerExt so that there's only ever a
> single handler irrespective of which call you use?  Can't Handler
> register its own private handler with HandlerExt which strips off the
> thandle and calls the user-supplied handler?  Internally, only the Ext
> variant need be invoked, with Handler wrapping it transparently.

Hum, I'm not sure we can do that (or that would be tricky) since TIFFSetErrorHandler() 
must return the previous handler with a type of TIFFErrorHandler. Or actually that would 
mess a sequence fo calls of TIFFSetErrorHandler() and then TIFFSetErrorHandlerExt(), 
where the later would then return our internal ErrorHandlerExt wrapper instead of 
NULL currently.

I've just applied Paavo's patch for now. This should fix crashing situations.

Even

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com