Hi Of course, it is OK for me to revert the tags added by DNG update with a #if 0 / #endif.
Regards, Su -----Ursprüngliche Nachricht----- Von: Even Rouault [mailto:[email protected]] Gesendet: Mittwoch, 7. Juni 2023 19:38 An: Bob Friesenhahn <[email protected]>; Su_Laus <[email protected]> Cc: [email protected]; Kurt Schwehr <[email protected]> Betreff: Re: [Tiff] 4.5.1 release soon > This issue (causing "Stack Overflow" in formerly correctly written > applications) seems like it will be important for some applications. > It certainly struck GraphicsMagick: > > https://gitlab.com/libtiff/libtiff/-/issues/575 Yes, that's definitely annoying. The whole TIFFGetField/TIFFSetField API is hard to use safely. In an ideal world, we'd have a set of different signatures like TIFFGetFieldAsInt32(TIFF*, ttag_t tag, int32_t* retValue), etc. but I've the feeling that would be a significant work (especially if we want to be tolerant on using such a function to get uint8/int8/uint16/int16 values as well) The annoying aspect of #575 is that it breaks in a patch release. One possibility would be to revert the tags added by the DNG update (possibly just #if 0 / #endif the declaration of the new tags) for 4.5.1, and re-enable it for 4.6.0. @Su, would that be OK for you ? > > The suggested work-around caused the program to not work with older > libtiff, and even the most recent release. I just put a fix into > GraphicsMagick to solve that. Can you point to the commit with your fix ? That could potentially be interesting for others Even -- http://www.spatialys.com My software is free, but my time generally not. _______________________________________________ Tiff mailing list [email protected] https://lists.osgeo.org/mailman/listinfo/tiff
