2017.03.17 17:01 "Re: [Tiff] TIFFSetErrorHandler vs TIFFSetErrorHandlerExt", by Dinesh Iyer

Hi Bob,

It look like I need to to use TIFFClientOpen to open the file and pass in my own routines for reading/writing seeking if I need to pass in client data. Am I correct? This appears to be rather wasteful if all I want to do is pass some client data. Is there a way to force the library to use defaults if one is not provided?

Regards,
Dinesh

On Fri, Mar 17, 2017 at 12:07 PM, Dinesh Iyer <dsi.maillist@gmail.com> wrote:

Hi Bob,

I am not sure I understand how to pass custom client data into the handler. I was under the assumption that once the TIFFOpen succeeds, I could update the client_data field. However, this does not appear to be possible. Additionally, I am not sure how to handle warnings generated during the TIFFOpen call.

Any help would be appreciated.

On Fri, Mar 17, 2017 at 11:53 AM, Dinesh Iyer <dsi.maillist@gmail.com> wrote:

Thanks Bob.

If I understand you correctly, I cannot have multiple threads each with its own handler throwing errors/warnings. i need to ensure that only one thread does the error handling, am I correct?

As a follow up, do i have to set the client_data field with a pointer to my class such that it is accessible in the callbacks?

Regards
Dinesh

On Fri, Mar 17, 2017 at 10:53 AM, Bob Friesenhahn < bfriesen@simple.dallas.tx.us> wrote:

>> Hi team,

I need to do some custom error handling which requires me to pass in the pointer to my class that is doing the TIFF I/O. I need this because I need to deliver warnings/errors to my application through a specific mechanism.

I noticed that TIFFSetErrorHandlerExt does allow me to pass that as the first argument. I was wondering if it is sufficient to set one of the error handlers or do I have to set both. The same applies for warning

>>>> handlers as

well.

These functions are redudant and both may be used at once. If TIFFSetErrorHandler() was used, then its error handler will be called. If TIFFSetErrorHandlerExt() was used, then its error handler will be called. They are called in succession.

This means that you can just use TIFFSetErrorHandlerExt() and be happy.

The main problem with these interfaces is that the internal storage location is shared across threads so threads can't use different handlers unless they serialize access to libtiff.

>> bfriesen@simple.dallas.tx.us, http://www.simplesystems.org/u
>> sers/bfriesen/

GraphicsMagick Maintainer, http://www.GraphicsMagick.org/