2021.01.04 14:23 "[Tiff] Motions related to C99 use in libtiff", by Even Rouault

2021.01.06 18:00 "Re: [Tiff] Motions related to C99 use in libtiff", by Roger Leigh

libtiff is a C library. That would be broken C++ code and frankly none of our concern. At some point we have to draw a line and not accept responsibility for all the code in the universe.

It is not broken C++ code to use interface types as part of its implementation. C++ itself is "broken" in that the definition of a class must expose the complete interface (including "private" parts). It takes extra work to develop C++ interface code which entirely hides the implementation.

I think the main point being made here is asking where the remit of libtiff ends. It’s not the responsibility of libtiff to care about bindings in other languges, and while we should certainly consider the implications of changes we make to the C interfaces, use in other languages is out of our scope. Other project maintainers bear the responsibility for the correctness of their code. If we continue to permit access to the old type names for compatibility with e.g. the proposed TIFF_LEGAGY_TYPES macro, they will be able to transition to the standard types at their convenience.

Speaking for myself, my C++ libtiff wrapper code makes no use of the libtiff [u]intnn typedefs. I was concerned about the portability implications when I originally noticed them. It uses <cstdint> where necessary to use the standard sized types, and it uses templates to provide type-safe interfaces for getting and setting field values. It does not directly expose any of the libtiff types or functions.

I’m currently going through all the libtiff-using source packages in Debian to identify which are using the libtiff types, to identify the scope of the breakage if we disable the old typenames. I’ll have some more to write about this once I’ve finished going through the sources.

Regards,

Roger