LibTiff Mailing List
TIFF and LibTiff Mailing List Archive
August 2004
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
2004.08.25 17:57 "Re: Not-a-bug report, TIFFFdOpen (tif_win32) - TIFFClientOpen", by Frank Warmerdam
2004.08.26 09:27 "Re: Not-a-bug report, TIFFFdOpen (tif_win32) - TIFFClientOpen", by Joris Van Damme2004.08.26 09:27 "Re: Not-a-bug report, TIFFFdOpen (tif_win32) - TIFFClientOpen", by Joris Van Damme
Ross wrote:
> Please note that for some reason the tif_fd member is used by the
> tiff2pdf program. I'd be happy to just use tif_clientdata instead, a fix
> of a few lines.
> ...
> It is used in the fax2tiff program for the "smuggling of the file
> descriptor" and in the tiff2pdf program for enabling TIFFWriteFile
> functions to stdout.
> ...
> If the tif_fd is never otherwise addressed in the library code then it
> should be a simple matter to remove it.
OK, then that seems a worthy course of action, whether we remove the tif_fd or
not, because it will serve in 'cleaning up' either way.
> It can be presumed that other software uses the field.
>
> /*
> * Return open file's I/O descriptor.
> */
> int
> TIFFFileno(TIFF* tif)
> {
> return (tif->tif_fd);
> }
>
> What are the benefits of so doing besides the encapsulation of the type?
> If the benefits of encapsulating the type, if that is the right notion,
> outweigh breaking some existing programs which are easily updated if part
> of libtiff, then it would be worth doing. Let us not be too hasty.
> casual source code browsing does appear that it's OK to take it out.
Let's indeed not be hasty. But let's try to nevertheless be clean, maybe we can
have it both ways.
How about this:
- We change tiff2pfd and fax2tif to use clientdata, making tiff_fd unused in the
tools like in the library, the way you proposed.
- We add a TIFFFilenoSet function, that sets the tif_fd member. That way, we can
achieve an opaque TIFF* even for code that activelly uses this tif_fd, on the
one hand, and we'd have added a 'usefull' extra clientdata member accessable
for the code that already treats TIFF* as opaque on the other hand.
- We change the platform dependent tif_* units to use TiffFilenoSet, instead of
directly accessing the member, and are then able to enforce the rule that TIFF*
should be opaque in those units.
How does this sound to you?
Joris Van Damme
info@awaresystems.be
http://www.awaresystems.be
Download your free TIFF tag viewer for windows here:
http://www.awaresystems.be/imaging/tiff/astifftagviewer.html