LibTiff Mailing List

LibTIFF'ers

I've possibly found a bug in tif_dirread.c .  It is not serious, and may be
a "Works as Designed" feature.  It only seems to occur on bad files anyway,
so it may not need to be fixed.  Here is the scoop:

I have a file that has a tag written with the wrong data type.  The data
type is supposed to be "double" but it is written as "short".  The next tag
in the file is a private tag, unknown to LibTIFF.  Three independent
tiffdumpers show that all the tags in the file are in ascending order.

when opening the file with LibTIFF, in the TIFFReadDirectory function, I get
a warning message that the bad tag has the "wrong data type".  This is
expected.  

However, as part of processing this error, LibTIFF increments the index into
the ordered list of known tags.  The next tag in the file is unknown to
LibTIFF, and is less than the next known tag.  This causes LibTIFF to emit a
warning message for this tag saying "invalid TIFF directory: tags are not
sorted in ascending order".   This tag also generates the "unknown field
with tag..." message, as expected.

So, what is the problem ? This is a bad file, and after any errors are
encountered, behavior cannot be guaranteed to be correct anyway, right ?
Unfortunately, the customer is more concerned about the wording of the error
message than the fact that it is a bad file.  We can explain the bad data
type and the unknown field, but the words "invalid TIFF directory:" seem to
make them concerned out of all proportion.  The worst part is, the tags ARE
in ascending order -- the only error message that really bothers them is the
one that is not true.

Note that if the data type on the previous tag was correct, we would not get
the "out of order" message. It is the handling of the data type error that
causes the next tag to be incorrectly reported as out of order.

I can get rid of the bogus error message by simply setting "fix = 0;"
immediately after the TIFFWarning call on/about line 268 of tif_dirread.c -
just before the "goto ignore;" statement.  However, I am not sure what the
ramifications of this setting are.  Will this cause problems with other
types of bad files ?  All of the other warnings seem to set "fix = 0;" , why
not this one ?  

I can provide more details upon request, but this message is getting long as
it is.

--
ed grissom
egrissom@ingr.com


AWARE [SYSTEMS]		Imaging expertise for the Delphi developer
		TIFF and LibTiff Mailing List Archive
	LibTiff Mailing List TIFF and LibTiff Mailing List Archive July 1998 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	1998.07.21 13:13 "Possible bug in tif_dirread.c", by Ed Grissom LibTIFF'ers I've possibly found a bug in tif_dirread.c . It is not serious, and may be a "Works as Designed" feature. It only seems to occur on bad files anyway, so it may not need to be fixed. Here is the scoop: I have a file that has a tag written with the wrong data type. The data type is supposed to be "double" but it is written as "short". The next tag in the file is a private tag, unknown to LibTIFF. Three independent tiffdumpers show that all the tags in the file are in ascending order. when opening the file with LibTIFF, in the TIFFReadDirectory function, I get a warning message that the bad tag has the "wrong data type". This is expected. However, as part of processing this error, LibTIFF increments the index into the ordered list of known tags. The next tag in the file is unknown to LibTIFF, and is less than the next known tag. This causes LibTIFF to emit a warning message for this tag saying "invalid TIFF directory: tags are not sorted in ascending order". This tag also generates the "unknown field with tag..." message, as expected. So, what is the problem ? This is a bad file, and after any errors are encountered, behavior cannot be guaranteed to be correct anyway, right ? Unfortunately, the customer is more concerned about the wording of the error message than the fact that it is a bad file. We can explain the bad data type and the unknown field, but the words "invalid TIFF directory:" seem to make them concerned out of all proportion. The worst part is, the tags ARE in ascending order -- the only error message that really bothers them is the one that is not true. Note that if the data type on the previous tag was correct, we would not get the "out of order" message. It is the handling of the data type error that causes the next tag to be incorrectly reported as out of order. I can get rid of the bogus error message by simply setting "fix = 0;" immediately after the TIFFWarning call on/about line 268 of tif_dirread.c - just before the "goto ignore;" statement. However, I am not sure what the ramifications of this setting are. Will this cause problems with other types of bad files ? All of the other warnings seem to set "fix = 0;" , why not this one ? I can provide more details upon request, but this message is getting long as it is. -- ed grissom egrissom@ingr.com

LibTiff Mailing List

1998.07.21 13:13 "Possible bug in tif_dirread.c", by Ed Grissom