2000.11.23 20:06 "Using libtiff without reading from a file", by Wolfram Bettermann

2000.11.23 23:39 "Re: Using libtiff without reading from a file", by Alex

TIFFClientOpen() is not perfect.

By some reason it takes pointers to all file access functions except Open, i.e a function that takes a file spec and returns a handle. I wish somebody fix this bug in LibTiff interface.

Why is that such a bad thing? In fact, what would be the 'file spec' if you want to read from memory? The one and only complete spec that is always suitable is a 32bit 'handle', which you can supply. If you want to work with open files, just open them first. You can assume they need to be opened anyway if LibTiff is to do something on their data, can you not?

TIFFClientOpen() is bad because it is incomplete. It suffices for TIFF data in core but fails for TIFF files embedded in archives, databases, resource forks, EPS files and OLE objects. We cannot assume that Open is trivial in all cases.

There are computers with segmented memory or separate address spaces for every process. The memory spec may need the process handle besides the address. Even in the single flat address space one can use ROT13 to convert address to a handle. MS Windows does it all the time to ensure the separation between the client and system code.

It is possible to open the file outside but it will be closed inside the library. This design obscures the program workflow and requires separate error handling for Open and other LibTiff functionws.

BTW, the use of a static variable for the error handler is another interface problem. The error handler function must be another parameter of TIFFClientOpen(). It cannot be set later because the error can happen during the call to TIFFClientOpen().