AWARE SYSTEMS
TIFF and LibTiff Mail List Archive

Thread

2017.03.17 14:29 "[Tiff] TIFFSetErrorHandler vs TIFFSetErrorHandlerExt", by Dinesh Iyer
2017.03.17 14:53 "Re: [Tiff] TIFFSetErrorHandler vs TIFFSetErrorHandlerExt", by Bob Friesenhahn
2017.03.17 15:53 "Re: [Tiff] TIFFSetErrorHandler vs TIFFSetErrorHandlerExt", by Dinesh Iyer
2017.03.17 16:07 "Re: [Tiff] TIFFSetErrorHandler vs TIFFSetErrorHandlerExt", by Dinesh Iyer
2017.03.17 17:01 "Re: [Tiff] TIFFSetErrorHandler vs TIFFSetErrorHandlerExt", by Dinesh Iyer
2017.03.17 17:06 "Re: [Tiff] TIFFSetErrorHandler vs TIFFSetErrorHandlerExt", by Bob Friesenhahn
2017.03.17 17:19 "Re: [Tiff] TIFFSetErrorHandler vs TIFFSetErrorHandlerExt", by Yakov Galka
2017.03.17 17:02 "Re: [Tiff] TIFFSetErrorHandler vs TIFFSetErrorHandlerExt", by Bob Friesenhahn
2017.03.17 21:02 "Re: [Tiff] TIFFSetErrorHandler vs TIFFSetErrorHandlerExt", by
2017.03.17 21:08 "Re: [Tiff] TIFFSetErrorHandler vs TIFFSetErrorHandlerExt", by Bob Friesenhahn
2017.03.17 22:23 "Re: [Tiff] TIFFSetErrorHandler vs TIFFSetErrorHandlerExt", by Roger Leigh
2017.03.17 22:40 "Re: [Tiff] TIFFSetErrorHandler vs TIFFSetErrorHandlerExt", by Paavo Helde
2017.03.17 23:03 "Re: [Tiff] TIFFSetErrorHandler vs TIFFSetErrorHandlerExt", by Bob Friesenhahn
2017.03.18 10:53 "Re: [Tiff] TIFFSetErrorHandler vs TIFFSetErrorHandlerExt", by Yakov Galka

2017.03.17 22:40 "Re: [Tiff] TIFFSetErrorHandler vs TIFFSetErrorHandlerExt", by Paavo Helde

On 17.03.2017 23:08, Bob Friesenhahn wrote:

On Fri, 17 Mar 2017, rleigh@codelibre.net wrote:

Could I suggest a perhaps controversial but useful solution for handling errors, which might be worth your consideration.

If the libtiff core were to use a C++ TIFF class reporting errors via exceptions, it would be possible for this to be wrapped by the existing C API calling the C++ code in a try/catch block and reporting any thrown errors via the handlers. Or direct use by C++ code without any of that

Unfortunately, throwing C++ exceptions through C code is not portable. It would require that the using program to be linked using the C++ compiler. The built library would only support one C++ compiler (perhaps just one of several C++ dialects supported by the same compiler) due to C++ compiler run-time libraries and name mangling.

A C++ library can have an interface defined purely in extern "C" functions. This does not help with exceptions (which cannot be passed through extern "C" functions (portably)), but it gets rid of the problems of compiler versions and name manglings.

I have developed an extern "C" interface for a large C++ library and I think this has proved to be quite a success. The error handling is done by try-catch in each interface function and storing the exception in thread-local storage. There is a special interface function for obtaining the last stored error message in the current thread which the client code is supposed to use in the case of a failing call.

This does not mean libTIFF should be converted to C++. It's just a general remark that a library does not need to be developed in C in order to have C interface.

Best

Paavo