2016.12.13 17:40 "Re: [Tiff] one little ill-advised change in v4.0.7 broke functionality for HylaFAX", by Lee Howard

On 12/13/2016 12:54 AM, Even Rouault wrote:

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... and such a change really should not be done lightly because of the consequences to other software that utilize those exported tables. Yes, TIFFTAG_FAXRECVPARAMS is really just a HylaFAX thing... but as HylaFAX and libtiff were born of the same cloth by the same author - the correlation between TIFFTAG_FAXRECVPARAMS and the "Param" field in these tables is not imagined.

Thanks,

Lee.