LibTiff Mailing List
TIFF and LibTiff Mailing List Archive
November 2000
Previous Thread
Next Thread
Previous by Thread
Next by Thread
Previous by Date
Next by Date
Contact
The TIFF Mailing List Homepage
This list is run by Frank Warmerdam
Archive maintained by AWare Systems
Thread
2000.11.23 23:39 "Re: Using libtiff without reading from a file", by Alex Cherepanov
Joris wrote: > Alex wrote: > > 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().