2021.01.18 16:50 "Re: [Tiff] C99, part 2", by Bob Friesenhahn
The one bit I’m not convinced by is the “legacy-types” option at configure time. It adds additional complexity and variability to a libtiff installation which might cause more problems than it’s worth, especially when you can just compile with the “TIFF_LEGACY_TYPES” macro for the same effect. If there are no objections, I’d like to drop this part.
The only use I can think of for it is as a quick fix for someone facing a bunch of things which won't build. With this option, they could flip a switch in libtiff and report bugs to the packages which failed to build. Without, they'd have to delay the libtiff upgrade until all the packages are fixed.
It is indeed a "quick fix". I will point out again that the API being changed has been documented for perhaps 30 years already. Systems I used since the early '90s have had libtiff manual pages installed just like the manual pages for system APIs and commands supplied by the system. These API specifications were very clear about the types which should be used.
The applications which would now fail to complile without the "quick fix" are in fact the apps which were carefully written to be conformant to the published libtiff API. The API specifications were treated as specifications rather than a mere analogy. Many of these applications which would fail to compile without the "quick fix" are very well known to the community.
In addition to trying to keep libtiff up to date as pertains to standards and quality metrics, a key function of the libtiff project is to get bug and security fixes out to those who need them. Without the "quick fix", there would be more delay due to adapting to the new libtiff requirements so that dependent code will again compile. Even with the "quick fix" there is delay since existing build scripts need to be changed and the builds need to be re-tested.
GraphicsMagick Maintainer, http://www.GraphicsMagick.org/
Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt