TIFF and LibTiff Mail List Archive

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


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