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
"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
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
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>