2017.03.04 19:53 "Re: [Tiff] started seeing breakage with libtiff", by Even Rouault

On samedi 4 mars 2017 18:51:20 CET jcupitt@gmail.com wrote:

tar xf tiff_4.0.6-2ubuntu0.1.debian.tar.xz
tar xf tiff_4.0.6.orig.tar.gz
cd tiff-4.0.6
for i in ../debian/patches/*.patch; do patch -p1 < $i; done

Actually to reproduce, you need to apply the patches in a precise order with

for i in `cat ../debian/patches/series`; do \
        patch -p1 <../debian/patches/$i; done

I've then compared the patched libtiff/tif_dirread.c with the official one from CVS, and I understand now what happens in Debian/Ubuntu.

It appears that the following snippet
                  if( dp->tdir_count > 0 && data[dp->tdir_count-1] != '\0' )
                        {
                            TIFFWarningExt(tif->tif_clientdata,module,"ASCII value for tag \"%s\" does not
end in null byte. Forcing it to be null",fip->field_name);
                            data[dp->tdir_count-1] = '\0';
                        }

that in official libtiff is applied in the TIFF_SETGET_C16_ASCII cases (line 5017 in HEAD) and in the TIFF_SETGET_C32_ASCII cases (line 5194 in CVS HEAD) has been wrongly applied in Debian in the TIFF_SETGET_C16_UINT8 case (line 5008) and TIFF_SETGET_C32_UINT8 case (line 5180)...

This explains the warning about the JPEGTables...

Unfortunately "make check" in the Debian patched libtiff still passes, so they have some excuse. Not so surprised since the test suite is rather small.

Even

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