2002.12.04 11:25 "Bugs in tiff_dirread.c?", by Torsten Hentschel

2002.12.04 11:25 "Bugs in tiff_dirread.c?", by Torsten Hentschel


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

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