2016.07.05 09:41 "[Tiff] Proposed API improvements", by Yakov Galka

2016.07.19 14:17 "Re: [Tiff] Proposed API improvements", by Olivier Paquet

2016-07-19 9:36 GMT-04:00 Yakov Galka <ybungalobill@gmail.com>:

> There doesn't seem to be any
> shortened name in the API though so I believe TIFFTileDimensions would
> fit better.

This is not actually true. Just a few I found: Dir(ectory), Proc(edure), Ext(ention), Info(rmation). Not that I'm trying to take a position here.

Ok, fair enough, although Directory is spelled out everywhere as far as I can see. I still have a preference for long names when they are not excessively long but it's a minor detail.

Not exactly. The functions which open files have some code that reports errors before a TIFF structure was created. It is possible to pass clientdata and errorProcs as deep as needed, but it isn't pretty.

There is only one error and it's "can't open file". Then TIFFClientOpen() is called and one of the first thing it does is allocated the TIFF structure. There's no need to pass the information around really far.

I start leaning towards the way SQLite handles errors. There are no callback functions (which solves problems wrt longjmp and C++ exceptions, which libtiff currently eludes), and instead it sets an error on the sqlite3 object. If some operation fails the user can query the sqlite3 object for the latest error string. The sqlite3_open functions return a valid sqlite3 object even on failure, and it contains the error description if they failed (they indicate failure by a returned error code). The only possible error condition where an error string is not available is when sqlite3 could not be allocated, but this happens only in out-of-memory condition.

What do you think?

I suppose it's an ok design but it's also a large change in how the API works. It would require invasive changes to all client code instead of only the open functions. It also becomes tricky if a call emits multiple error messages (eg. a directory has multiple invalid tags). And it doesn't do anything better than putting the error handler in the TIFF handle, just different.

Olivier