LibTiff Mailing List
TIFF and LibTiff Mailing List Archive
February 2009
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
Thread
2009.02.06 10:44 "Re: assertions, and building with DEBUG/NDEBUG", by Joris Van Damme
Frank, folks, This is about http://bugzilla.maptools.org/show_bug.cgi?id=1994. I've currently no bugzilla log-in, and/or I forgot about it, so I'll go ahead and abuse the mailing list. As far as I can make out, the bug is due to crapy logic in TIFFReadDirectory, in tif_dirread.c. It is not by my hand, but here is my humble opinion on it anyway. The procedure goes about it in different stages. - In a first stage, the primary tags TIFFTAG_SAMPLESPERPIXEL and TIFFTAG_COMPRESSION are read in specific hacky manners. The tags themselves are next signalled with an IGNORE flag, disabling further duplicate processing in subsequent stages. This stage is a based on tag finding in the IFD. - In a second stage, tags for which there is no know definiton get an auto-generated definition auto-merged into the definition list (which is a problem all by itself, private unknown tags can have different datatypes in different IFDs, and if you hack around that problem there's nothing actually left to define, so the proper and correct way would be enabling the library to work with tags that simply don't have a known definition at all, but that's beside the point here). Also, in this stage some more primary tags are read and again they're signalled with an IGNORE flag. This stage is based on cycling through the tags, rather then finding specific tags in the IFD. - In a third stage, some more primary tags are read in specific manners, and tags that aren't in the list of specially handled ones and that aren't flagged IGNORE are read in the generic manner. Again, this stage is based on cycling through the tags, rather then finding specific tags in the IFD. The thing is, since the compression tag is read in the first stage, and flagged IGNORE, the hacky second and third stages aren't supposed to have to deal with it. Thus, a routine like TIFFFetchNormalTag for example, is never called for the compression tag. Only, in this particular buggy file we've two TIFFTAG_COMPRESSION tags. The first one is signalled IGNORE when it's specifically found in the first stage, but the second one isn't. The second and/or third stage then cycle through the tags, and find the compression tags that aren't signalled IGNORE, and deal with them in default manners intended not ever to deal with the compression tag. A quick fix would be to have any compression tags ignored in the second and third stages, whether or not their IGNORE flag is set. Still, that leaves the crappy logic intact and similar problems with other tags are guaranteed to arise another day. A more throrough fix would be to extend the preceding call to TIFFReadDirectoryCheckOrder near the top of the procedure. Currently, it just checks order and emits a warning if tags aren't sorted. I propose we replace this with a proper sorting routine that guarantees tags are unique. That doesn't completely fix all logic to my taste, but it does exclude this exact problem on any tag for all future and requires minimum code change. Furthermore, it will continue to work with potential future code change where more/less tags might be read in special manners in more/less/existing stages. Another potential fix might be to have a local array of flags inside TIFFReadDirectly, replacing the functionality that is currently in the IGNORE flag, where the array is based on the tag code rather then the tag instance such that it works when there's duplicate instances. The drawback is the big array, and I feel it's a big kludgy. Best regards, Joris