On 29/12/2025 11:08, Roger Leigh via Tiff wrote:
I mentioned this as a possibility during discussion
> in mid December,
Please be aware that moving libtiff to C++ instead of C would cause
problems for various pieces of software that depend upon it.
The most obvious case, from my point of view, is Ghostscript.
We are careful to avoid any compulsory dependencies that depend upon
C++, as we have to run on lots of systems where C++ presents a problem.
As a very brief bit of context and summary. I’ve long been
> unsatisfied with the base C API of libtiff. It’s unsafe,
> doesn’t support multi-threading well, is hard to use correctly,
> is stateful where it doesn’t need to be, and has inconsistent
> and hard to use error handling.
All of which case be solved without resorting to C++.
The proposal includes elements from all three of these
> implementations, and is really asking the question: what would
> libtiff look like if we implemented it wholly in C++, but also
> used extern "C” linkage to completely retain the C API and ABI as they
> are today.
Writing it in C++, and offering a C API (unchanged or not) does NOT
address the issues I'm concerned about.
Any use of C++ (in particular the standard library) is a bridge too far
for at least some of your target audience.
Now, I imagine that some people will argue that losing support for such
"legacy" code is just too bad. So be it, but be aware that this means
the old version of the lib will likely live on as a source of security
bugs for years to come.
Robin
_______________________________________________
Tiff mailing list
[email protected]
https://lists.osgeo.org/mailman/listinfo/tiff
