2021.01.05 08:30 "Re: [Tiff] Motions related to C99 use in libtiff", by Roger Leigh

I don't much care about ABI, as in the packaging world having to rebuild things is not a big deal. What is a big deal is not being able to build things because they use the old API still, but the old API is gone. This is extra tricky when there are packages that people care about but which do not have active maintenance. Even knows how difficult this has been for proj.

Yes, but for PROJ, we completely changed API. Here we are discussing about changing "uint32" to "uint32_t" in code. Shouldn't be a big deal...

There's a momentum currently thanks to Roger to do those changes. I'm afraid having to deal with a multi-year transition of API will loose that momentum. If there's an easily way to use the old API, people will use it and defer the move to the new API until the old API is completely removed. So you're just loosing time.

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?

Can we do a grep through the whole lot and determine the subset which require updating, and then push those updates upstream? I’ve done a few transitions this way for other projects, and it was manageable.

It is described that changing "uint32" to "uint32_t" in code should not be a big deal but this impacts a lot of software, including some which is barely/seldom maintained but otherwise works just fine.

I suggest that if the API is changed to be based directly on stdint.h types, that C-preprocessor definitions for the old type names be provided to allow existing software to continue to compile.

For example:

   #define uint32 uint32_t

I don’t know if you looked over the proposed changes in detail, but this is already covered. See this bit <https://gitlab.com/rleigh/libtiff/-/blob/bb0c8ac183e263759ed9e6a6c0563d35b9459c77/libtiff/tiff.h#L68>. It’s using typedef rather than #define, but that’s just a detail.

We will still be throwing users of MinGW under the bus (so to speak) if they do not have C'99 printf formatting support engaged (via a wrapper) since MinGW depends on a very old runtime DLL which does not support C'99.

Even with latest MSYS2 which comes with a latest MinGW-w64 compiler, I have still not gotten to the bottom of C'99 printf formatting issues.

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.

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.

Regards,

Roger