Raphael Hertzog <hert...@debian.org> writes: > I agree on all this but somehow I have the feeling that we can still > do better for example by blacklisting tags that are known to use a single > extension and refusing to handle them as custom > > My problem is that I'm not sure that we have a comprehensive list of such > tags. In particular not one that is available in some structure. In other > words, we would have to build up that list and hardcode it into the code. > > We could build that list from all the tags which are used in CopyField > (as opposed to CopyField2 or CopyField3) in the various tools. That would > be a good start IMO.
You are probably right. However I am still a bit confused with this. According to http://bugzilla.maptools.org/show_bug.cgi?id=2564: "However, `field_passcount' is always assigned TRUE if the tag is processed by `_TIFFCreateAnonField()'. This happens on unsuccessful invocations of `TIFFReadDirectoryFindFieldInfo()'" Oh, wait, only happens on *unsuccessful* invocations of `TIFFReadDirectoryFindFieldInfo()' - oops - missed that detail. What does the TIFFReadDirectoryFindFieldInfo function do? What situations is TIFFReadDirectoryFindFieldInfo unsuccessful? > In any case, this is really a hack to mitigate the issue that should be > fixed with a better API IMO. (Feel free to share my comments with > upstream) Definitely. Having a C function take a variable number of arguments that can vary depending on runtime state sounds like a recipe for disaster to me. You could perhaps mitigate by requiring an extra parameter that declares the number of options you are parsing, however I think the chances of getting it wrong are high. -- Brian May <b...@debian.org>
