2002.12.04 11:25 "Bugs in tiff_dirread.c?", by Torsten Hentschel
<x-flowed>Hi,
when I am looking at the source of tiff_dirread.c (v3.5.7, Rev. 1.6) I am wondering, whether the functions
TIFFFetchShortArray and
TIFFFetchByteArray
are buggy when used in a special case. I suspect they return the wrong order of the values, if the value array fits into the encoding of the directory entry's offset.
I am asking this, because when I use ``tiffdump'' to show the directory content of the example image jim___gg.tif from ftp://ftp.remotesensing.org/pub/libtiff/v3.4pics.tar.gz, the last tag is printed as:
HalftoneHints (321) SHORT (3) 2<254 1>
But when I use ``tiffdump'' from DaVince Tools (http://www.davince.com) it prints the last tag as
Tag HalftoneHints 321: type SHORT: count 2<1 254>
When I am looking at the encoding of the tag using a hex dump utility (tag offsets's encoding starts at 0xbe) I see the following bytes (in that order):
01 00 fe 00
Byte order of that file is obviously little endian.
What I suspect now is, both functions (TIFFFetchShortArray and TIFFFetchByteArray) use dir->tdir_offset to decode the values from, if the value fits into there. They do use tif->tif_header.tiff_magic to determine the byte order. But the value of dir->tdir_offset has already been brought into host byte order, right?
Please tell me if I am wrong or not, I am very curious about this.
Kind reagards,
Torsten Hentschel
Torsten Hentschel
Team Lead Software Development
AuthentiDate International AG
Grossenbaumer Weg 6
40472 Duesseldorf
phone: +49 (0)211 43 69 89 63
fax: +49 (0)211 42 69 89 19
Email: torsten.hentschel@authentidate.de