LibTiff Mailing List
TIFF and LibTiff Mailing List Archive
November 2009
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
2009.11.07 00:24 "Re: TIFFDirEntry type moved from tiff.h to tiffiop.h in v4.0", by Lee Howard
Joris Van Damme (AWare Systems) wrote: > Lee, > >> HylaFAX is only using it in one source file: hfaxd/FileTransfer.c++. >> >> http://hylafax.cvs.sourceforge.net/viewvc/*checkout*/hylafax/hylafax/hfaxd/FileTransfer.c%2B%2B >> >> >> >> You'll see that it's used in several places. > From a quick skim through the code, am I correct in assuming this code > assembles memory structures to pass to LibTiff as file input, so as to > persuade LibTiff in decoding compressed data that comes from other > places? Sort-off like wrapping dog medicine in a piece of steak so as > to persuade the beast to eat it. Yes, I think that's correct. > If so, yes, that would be a place where the old TIFFDirEntry structure > had a good purpose. Or maybe not, since structures depend on compiler > packing and padding settings, and should actually not be used to > encode fixed bit/byte patterns in a future-proof and portable way, I > guess. > > The easiest way out would probably be to completely ignore that last > issue, and define a new, local OldClassTiffDirEntry structure that is > completely identical to the old TIFFDirEntry of the old > ClassicTIFF-only LibTiff, as you're never going to hit the ClassicTIFF > 4 gigabyte boundary in this particular application. Next, do a > search&replace on this code file. That should fix it. > > That would be a FileTransfer.c local fix, rather then a fix inside > LibTiff, but I do feel that is probably most appropriate here. This works for me. Thanks, Lee.