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:23 "Re: [Tiff] TIFFSetErrorHandler vs TIFFSetErrorHandlerExt", by Roger Leigh

On 17/03/2017 21: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.

I like C++ but libtiff needs to remain a plain C library.

Note I'm not suggesting that exceptions be thrown through C code; if the C++ code is wrapped by 'extern "C"' functions, these could catch and handle the exceptions internally. This is the approach taken by e.g. the Mesa OpenGL implementation which has a C ABI but uses C++ internally.

If a C++ ABI was exposed, it would introduce additional linking requirements if static. That's something which could be done as a separate step though--if used internally without using the C++ standard library, it should be completely self-contained and could have an identical ABI to the existing implementation.

Keeping libtiff as a plain C library is of course a fine direction; I just wanted to mention this as a potentially beneficial direction which could be taken, particularly if you wanted to cater for better usage from C++ with regard to error handling, and also things like type-safe field access.

Regards,
Roger