On 13 Dec 2025, at 15:05, Greg Troxel via Tiff <[email protected]> wrote:
>
> Roger Leigh via Tiff <[email protected]> writes:
>
>> Over the next few weeks, I’m going to be looking at opening a series
>> of merge requests to address various categories of static analysis
>> warning in the codebase, plus enabling specific compiler warnings by
>> default to check for them by default in the CI builds. The aim being
>> to improve the quality and robustness of the codebase. Most of these
>> are fairly trivial to implement, but questions such as the above
>> really depend upon what the original intentions were and any
>> compatibility constraints we have to factor in.
>
> I think it would be good to be clear on where we are and where we're
> going in terms of system requirements to build tiff. If that's C99 and
> some degree of POSIX compliance, then perhaps the main path can be just
> to typedef tmsize_t to size_t, and to band-aid it for deficient
> platforms.
At the moment, I think it can be broadly summarised as:
C99 on POSIX, or
C99 on Windows
(Or C99 on a freestanding platform if you write your own glue code for I/O)
The common factor is that C99 is a requirement on every platform.
In terms of future system requirements, it really depends upon where we want to
go with libtiff long-term.
Everything I’ve done with libtiff over the last 15 years has been a C++
application, with one exception being a test tool for an embedded application
where C was used. I have written RAII wrappers around libtiff to make it
type-safe and to handle errors consistently. These are all arguably defects in
the C API and/or the C implementation. So I’ve used the C API, but I have
never liked it. And when you look at the continuous stream of CVEs and defects
which are primarily arising from implementation and design defects arising from
the codebase’s C legacy, I do think we could do better to modernise the
codebase and make it more robust. There’s a reason so many CVEs are found in C
image libraries. I would like to continue to use libtiff, but C is not going
to cut it long-term, especially with government recommendations to stop using
unsafe languages. It’s clearly going to get phased out over the next few years
for many uses, including a lot of embedded uses especially where
safety-critical. It’s not going to be possibly to justify its use,
particularly when the quality of the library could be much better.
One approach we could take is to migrate the core library to C++ while
maintaining the existing C API and ABI identically. There could then be a
legacy C API while the internals are refactored to be clean modern C++ with a
matching clean C++ API to match. And/or with a clean C API to replace some of
the legacy types and functions which are the cause of problems. When I look at
the design patterns I use in a modern C++ embedded application like using
std::expected for error and value propagation it’s so much simpler and more
robust. Not trying to encode errors in negative values removes that abuse of
signed vs unsigned at a stroke, for example. We could do that and retain the
existing C API, but with significant quality improvements to the core library
(and the tools). Even’s work in https://github.com/libertiff/libertiff is
instructive in showing what such an implementation could look like.
https://gitlab.com/codelibre/ome/ome-files-cpp/-/tree/master/lib/ome/files/tiff?ref_type=heads
is the opposite way around, wrapping the C API with a safer interface on top
(but the C API still results in some limitations).
Another would be to do the same but use Rust. It also can support a public C
API while having a safe implementation.
A number of C libraries on Linux use these approaches, including mesa.
We could quite easily manage an incremental C++ refactor and migration while
retaining the C API. For Rust, it would likely be easier to start in a
separate repository.
The other side of this isn’t so much the implementation language but testing.
The project has some basic tests, and in places some more detailed tests, but
it has no comprehensive unit or integration testing of modules. There’s no
provision for mocking or faking for tests to do effective unit testing in
isolation. If we were to do one thing after fixing the major static analysis
defects, I would say it would be to improve test coverage to include extensive
unit and integration testing and to expand our collection of test images to
improve the image reading.
I did suggest a few years back that we could be using tools like GoogleTest and
FFF to do this. I still think we should look at it if there are no objections.
> A second concern is that a warning rototill risks breakage on platforms
> not tested, and usually CI is a very limited set. Besides GNU/Linux,
> macOS, and Windows, I'd want to see a couple of BSDs and something from
> the illumos family. Also, CPU variety: not just i386/x86_64/aarch64,
> but also earmv6 or v7, sparc or sparc64, ppc, or at least something big
> endian. Perhaps that's an alpha release after things are ok in CI.
It’s not difficult to add in additional platforms to the GitLab CI, either
cloud-based or self-hosted runners. I previously had ARM64-Linux or
ARM64-FreeBSD on Raspberry Pis hosted locally. I currently have a FreeBSD-13
[TrueNAS Core] system hosting FreeBSD runners and Linux and Windows CI systems
via Bhyve. I’m also in the process of bringing up a replacement FreeBSD-15
system with more capacity. I also recently bought a Mac mini which hosts a
GitLab runner in UTM. I can add libtiff runners to these systems to expand
platform and processor coverage. But guaranteeing 24/7 availability and
connectivity for these systems is not possible.
For more esoteric platforms, it is possible to add runners for these as well.
But it would require commitments in terms of hosting, maintenance and network
bandwidth and connectivity. None of these things are free, so I would like to
keep the set of tested platforms limited to those providing the largest
cost:benefit. I don’t have particular interest in supporting anything which is
obsolescent, and would prefer to focus on systems in active use.
Kind regards,
Roger
_______________________________________________
Tiff mailing list
[email protected]
https://lists.osgeo.org/mailman/listinfo/tiff
