AWARE [SYSTEMS] Imaging expertise for the Delphi developer
AWare Systems, Imaging expertise for the Delphi developer, Home TIFF and LibTiff Mailing List Archive

LibTiff Mailing List

TIFF and LibTiff Mailing List Archive
December 2016

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



Valid HTML 4.01!



Thread

2016.12.13 04:56 "one little ill-advised change in v4.0.7 broke functionality for HylaFAX", by Lee Howard
2016.12.13 08:54 "Re: one little ill-advised change in v4.0.7 broke functionality for HylaFAX", by Even Rouault
2016.12.13 17:40 "Re: one little ill-advised change in v4.0.7 broke functionality for HylaFAX", by Lee Howard
2016.12.13 18:06 "Re: one little ill-advised change in v4.0.7 broke functionality for HylaFAX", by Even Rouault
2016.12.13 18:52 "Re: one little ill-advised change in v4.0.7 broke functionality for HylaFAX", by Lee Howard
2016.12.13 23:19 "Re: =?utf-8?q?one_little_ill-advised_change_in_v4=2E0=2E7_brok?= =?utf-8?q?e_functionality_for_HylaFAX?=", by <mickey.rose@seznam.cz>

2016.12.13 18:06 "Re: one little ill-advised change in v4.0.7 broke functionality for HylaFAX", by Even Rouault

On mardi 13 décembre 2016 09:40:14 CET Lee Howard wrote:
> On 12/13/2016 12:54 AM, Even Rouault wrote:
> > Lee,
> > 
> > sorry for the inconvenience. I'm all for reverting if that broke
> > things of course, but even with your explanations and looking at the
> > code, I don't understand how it may affect external software.
> > 
> > My grep'ing of the code shows that the TIFFFaxTabEnt structure and the
> > 3 tables TIFFFaxMainTable, TIFFFaxWhiteTable and TIFFFaxBlackTable are
> > only used by tif_fax3.h, tif_fax3.c & tif_fax3sm.c. And I don't see
> > any connection at all with TIFFTAG_FAXRECVPARAMS, which has no
> > specific (AFAICS) processing in libtiff.
> > 
> > Am I missing something or is it HylaFAX that uses libtiff internals in
> > some ways ?
> 
> Those tables are exported.
> 
> # nm -D /usr/lib64/libtiff.so | grep TIFFFax
> 000000000001b550 T _TIFFFax3fillruns
> 0000000000049740 R TIFFFaxBlackCodes
> 0000000000049f00 R TIFFFaxBlackTable
> 0000000000061f00 R TIFFFaxMainTable
> 00000000000499e0 R TIFFFaxWhiteCodes
> 0000000000059f00 R TIFFFaxWhiteTable
> 
> HylaFAX has its own set of those tables...
> 
> # nm -D /usr/lib64/libfaxserver.so.5.5.9 | grep TIFFFax
>                   U _TIFFFax3fillruns
>                   U TIFFFaxBlackCodes
>                   U TIFFFaxBlackTable
>                   U TIFFFaxMainTable
>                   U TIFFFaxWhiteCodes
>                   U TIFFFaxWhiteTable
> 
> I'm not yet sure why HylaFAX is preferring to use libtiff's tables over
> its own, but the fact remains that the tables exported by libtiff (is
> this considered ABI?) changed due to the referenced code change...

There was no hint that it was supposed to be part of the ABI (the "extern" declaration 
seemed only there because the tables are defined in tif_fax3sm.c and used in tif_fax3.c). 
Ideally HylaFAX should not rely on that, or there should be a cleaner way in libtiff to export 
the tables (a get function) and the structure should be defined in a public header of libtiff.

> and
> such a change really should not be done lightly because of the
> consequences to other software that utilize those exported tables.

Hum "I see" (not completely to be honest). Looks like in the above Hylafax imports libtiff 
tables (the U must be undefined, hence imported). OK so it must also have its redefinition of 
typedef struct TIFFFaxTabEnt in its code, since tif_fax3.h is not installed (or it has a copy of 
tif_fax3.h) ?

OK, I'll revert that with a prominent warning so that the next one that touches this code is 
aware of those tricky aspects that cannot be anticipated from libtiff code itself.

Even


-- 
Spatialys - Geospatial professional services
http://www.spatialys.com