TIFFDirEntry type moved from tiff.h to tiffiop.h in v4.0

[Lee Howard-2]

I'm trying to work at getting HylaFAX ported to support libtiff v4.0.

I'm running into a big problem illustrated by :

FileTransfer.c++:132: error: 'TIFFDirEntry' is used as a type, but is not
   defined as a type.

The cause is that HylaFAX was accustomed to finding TIFFDirEntry in
tiff.h (public include), and now it's been taken off into tiffiop.h
(private include).

What's the right way to have access to that type now in 4.0?

Thanks,

Lee.
_______________________________________________
Tiff mailing list: Tiff@...
http://lists.maptools.org/mailman/listinfo/tiff
http://www.remotesensing.org/libtiff/

[Joris Van Damme (AWare Systems)-2]

Lee,

> I'm trying to work at getting HylaFAX ported to support libtiff v4.0.
>
> I'm running into a big problem illustrated by :
>
> FileTransfer.c++:132: error: 'TIFFDirEntry' is used as a type, but is not
>   defined as a type.
>
> The cause is that HylaFAX was accustomed to finding TIFFDirEntry in
> tiff.h (public include), and now it's been taken off into tiffiop.h
> (private include).
>
> What's the right way to have access to that type now in 4.0?

There isn't one. Not just the struct has changed substantially in the move
to support BigTIFF, but also its usage changed drastically if I remember
correctly.

May I ask what it's being used for? At the time, LibTIFF maintainers
including myself figured it's highly unlikely LibTIFF calling code used that
structure, so we would be very interested to see how and why HylaFAX is
using it.


Best regards,

Joris

_______________________________________________
Tiff mailing list: Tiff@...
http://lists.maptools.org/mailman/listinfo/tiff
http://www.remotesensing.org/libtiff/

[Lee Howard-2]

Joris Van Damme (AWare Systems) wrote:

> Lee,
>
>> I'm trying to work at getting HylaFAX ported to support libtiff v4.0.
>>
>> I'm running into a big problem illustrated by :
>>
>> FileTransfer.c++:132: error: 'TIFFDirEntry' is used as a type, but is
>> not
>>   defined as a type.
>>
>> The cause is that HylaFAX was accustomed to finding TIFFDirEntry in
>> tiff.h (public include), and now it's been taken off into tiffiop.h
>> (private include).
>>
>> What's the right way to have access to that type now in 4.0?
>
> There isn't one. Not just the struct has changed substantially in the
> move to support BigTIFF, but also its usage changed drastically if I
> remember correctly.
>
> May I ask what it's being used for? At the time, LibTIFF maintainers
> including myself figured it's highly unlikely LibTIFF calling code
> used that structure, so we would be very interested to see how and why
> HylaFAX is using it.

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.

Recognize that most of the code there was written by Sam Leffler, so
it's going to have a familiar flavor to it.  :-)

Thanks,

Lee.

_______________________________________________
Tiff mailing list: Tiff@...
http://lists.maptools.org/mailman/listinfo/tiff
http://www.remotesensing.org/libtiff/

[Joris Van Damme (AWare Systems)-2]

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.

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.


Best regards,

Joris

_______________________________________________
Tiff mailing list: Tiff@...
http://lists.maptools.org/mailman/listinfo/tiff
http://www.remotesensing.org/libtiff/

[Lee Howard-2]

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.


_______________________________________________
Tiff mailing list: Tiff@...
http://lists.maptools.org/mailman/listinfo/tiff
http://www.remotesensing.org/libtiff/