Roger,
Thanks for all the thoughts you've put into devising this plan.
Personally, I wouldn't have issues with my usage of libtiff if it used
C++ for its internals, while retaining existing C API, and I'd be
curious to hear more details about others for which a dependency to the
C++ standard library would be a problem what the actual troubles would
be. There would be a decision to take if we don't want anymore to
"support" odd/marginal environments. I'm also on the board of only
"supporting" (or aiming at...) "modern" environments, that is things
like Linux, Windows, Mac, Android, WebAssembly, but maybe not 8/16-bit
micro-controllers, obsolete/esoteric OS (old UNIXes).
That said, I've some concerns about the benefit/(effort x risks) of your
proposal. Regarding libtiff "security", I see 2 main issues:
- TIFFGetField(). There's no way we can sanitize that one, be libtiff
being written in C++ or Rust. The interface of the function itself is
broken by design (va_list of varying number of parameters and types).
Top priority would be to introduce in the existing code base functions
like TIFFGetFieldAsUInt32(), TIFFGetFieldAsUInt32Array(),
TIFFGetFieldAsFloat64(), etc., or something similar that are type safe
in their API (with the functions doing reasonable type conversions when
possible). And push hard to deprecate existing usage of TIFFGetField().
- I believe there are a number of issues in the API contract of a number
of public functions, especially when read/write operations are mixed
(things like updating existing strips/tiles seem to have been an
after-though addition, that seem to mostly work now, but not without
hacks inside). I've fought for years in my use of libtiff in GDAL about
that. Those issues might be a mix of the core being written in a
memory-unsafe language, and also logic flaws/unspecified behavior in the
library regarding which functions can be called in which order.
I'm a bit unusure about the thread-safey aspects of your proposal, in
particular about the need for a mutex per TIFF handle. I would argue
that's the job of the caller to protect that. One option could be to
have a opt-in mutex (a bit like SQLite3's SQLITE_OPEN_NOMUTEX vs
SQLITE_OPEN_FULLMUTEX : https://sqlite.org/c3ref/open.html). Having
some higher level APIs that for example extract from multi-strip/tiles
at once and may use multithreading internally to decode several
tiles/strips in parallel would have strong value though (something I do
on the GDAL side of the TIFF reader typically).
If we really want to embrace the memory-safe bandwagon, we'd have likely
no other choice than doing a rewrite in Rust, and providing a C API that
is *mostly* compatible with the existing one, but possibly with gaps.
I'm undecided myself if that's something doable given the state of the
libtiff ecosystem and our own capabilities and availabilities (I'm
myself a total Rust noob, although I see that would be definitely
something worth embracing). Regarding Rust, it is not available for all
architectures, but it is available for all architectures that Debian
officially support, so I wouldn't be that concerned about the ones missing.
Even
Le 29/12/2025 à 12:08, Roger Leigh via Tiff a écrit :
Hi folks,
I mentioned this as a possibility during discussion in mid December, but I’ve
been spending some time thinking about this over the last couple of weeks, and
have taken the time to explore some of the details and write them up. There’s
far too much for an email, so I’ve written up a detailed proposal (with some
help from Claude Opus 4.5 for exploring the codebases in detail) and put it
here:https://gitlab.com/libtiff/libtiff/-/issues/771
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. Some alternatives for comparison:
OME Files TIFF wrapper (by me):
https://gitlab.com/codelibre/ome/ome-files-cpp/-/tree/master/lib/ome/files/tiff?ref_type=heads
A set of C++ wrapper classes over libtiff’s C API. Adds compile-time type-safe
field and pixel data access, supports multiple open directories (with
limitations due to the libtiff API).
Libertiff (by Even)
https://github.com/libertiff/libertiff/tree/master
Header-only, more modern and cleaner than OME Files TIFF wrappers, but exposes
less functionality overall. But the interface is very clean, and very well
done.
Bio-Formats TIFF (by Melissa Linkert)
https://github.com/ome/bioformats/tree/develop/components/formats-bsd/src/loci/formats/tiff
Java implementation with a lot of features and a lot of performance
optimisations.
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. I think it could result in a dramatic improvement in the quality
of implementation and its usability and performance, and open up libtiff to uses it
currently can’t meet. But it’s clearly a large change to make. However, from the
above examples, it’s something we’ve actually already done several times over
independently, so it’s not in any way new, it would largely be a repeat of what
we’ve already done but this time working within libtiff rather than trying to work
around its limited C API. The above three implementations are in production use,
some for well over a decade, so are not untested or unsafe—all of the design
proposals have been well proven.
Anyway, I’d be grateful for any feedback after you’ve looked over the linked
proposal. It’s written as a plan but it’s really just a series of proposed
ideas. This is trying to look at the future of libtiff, and how we can take it
forward while also keeping it fully usable and stable for its existing user
base.
Kind regards,
Roger
_______________________________________________
Tiff mailing list
[email protected]
https://lists.osgeo.org/mailman/listinfo/tiff
--
http://www.spatialys.com
My software is free, but my time generally not.
_______________________________________________
Tiff mailing list
[email protected]
https://lists.osgeo.org/mailman/listinfo/tiff
