2021.01.05 14:05 "Re: [Tiff] Motions related to C99 use in libtiff", by Bob Friesenhahn

It is my opinion that the cost to the world is too high if there is > not a soft transition. For example, Debian Linux has 210 packages > which will no longer compile if libtiff breaks its existing API

How many of these packages are using the old “uintn” and “intn” types?

That is unknown. The 210 packages are the ones listed as depending on libtiff. Only a subset directly interfaces with the libtiff API. Probably there is a dependency graph somewhere which would make direct dependencies more clear.

The CI builds are all passing on MinGW. Do we have unit test coverage of this functionality? If it’s important, it should be covered so that if it’s broken we will have visible test failures.

The test cases are testing TIFF features and there is nothing to verify that printf type statements are working as expected.

I do have a test program which tests the formatters as well as value range but it is intended to still compile (at least with MSVC) if the compiler lacks inttypes.h and stdint.h.

Looking around, I see there are people using C99 formatting with MinGW, so presumably there are workarounds we could employ with a bit more investigation. At the same time, implementation defects in other projects are at some level not our problem.

There is a __USE_MINGW_ANSI_STDIO define which appears to enable adding code (on top of the deficient underlying Windows DLL) to deal with C'99 printf specifiers. I found this documentation:

https://sourceforge.net/p/mingw-w64/wiki2/gnu%20printf/

However, I have seen a release accouncement which suggests that the above is not the correct approach with the latest MinGW-w64 compiler and that in fact the option may be enabled by default.

Bob

Bob Friesenhahn
bfriesen@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer, http://www.GraphicsMagick.org/
Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt