On 30 Dec 2025, at 01:49, William Bader <[email protected]> wrote: > > Recently there were issues with not having enough man power to support the > tiff utilities. Where will the time come from to do the C++ conversion and > maintenance? If the C++ conversion takes a long time to complete to stability > and feature parity, is there a chance that the C and C++ versions could fork? > What if someone proposes doing a rust conversion of the C++?
Hi William, The time would come from myself and anyone else interested in this. I do have time for maintenance of the core library, but my interest in the tools is limited. I would say there is a big difference between the core library and the tools in terms of maintenance. We all use the core library, but a lot of the tools have a much more limited audience, and some of them are thoroughly obsolete and (from my perspective) a fairly pointless maintenance burden to have to deal with. Yet we suffer from a regular stream of CVEs due to their multiple quality issues. Do we really need to generate PostScript, over two decades after the whole world moved over to PDF? And also generate PDF at the same time? Does that really bring much value? Why are we doing either when there are better applications out there for generating PDFs? You could make the same claim for a lot of them. If they do have any value, it would be to validate the behaviour and stability of the C API and the C ABI throughout the conversion, so long as they have robust and comprehensive tests (but most don’t). But for people like me (and likely yourself) whose primary use of libtiff is to link it into our applications, the tools are a complete distraction and an unproductive time sink. If we implement them in the same repository, I don’t think the C and C++ versions would fork, because they would be one and the same thing. The C API would ultimately end up as a thin compatibility wrapper around a C++ core. This is exactly what C libraries like Mesa do. You wouldn’t know they were C++ libraries from the outside. Regarding Rust, there is already a Rust tiff library https://github.com/image-rs/image-tiff but it’s quite limited. If anyone wanted to do a Rust conversion, they would currently need to do it through the exported C ABI. It would need to be made a lot safer first. I don’t see that being practical with the current implementation; it might become possible after a C++ conversion, plus some improvements to the C API as well. > Could the proposed C++ API be done as a front-end for C API to give time for > testing and experimentation before converting the code base and possibly > locking in a design that might have issues? Initially yes, though I’d want to turn that around at some point (but in a completely transparent way). We would likely not freeze the C++ API during the transition, but keep the C API stable and usable at all times. You can actually see the first step here: https://gitlab.com/libtiff/libtiff/-/pipelines/2234658359 If you look in the “compat” column, these jobs build libtiff as C++; we already have the interfaces marked extern “C” so it’s retaining the C ABI even at this stage. The next step would be to rename the .c files to .cpp and this would then be the codebase converted and building as C++ (but with no code changes at all). Everything following that would be small stepwise changes which preserve the C API and ABI at every step along the way. > I have a Linux C application that uses libtiff. If I continue using the C API > after the C++ conversion, would I only need to add -lstdc++ to the link after > -ltiff? You shouldn’t need to make any changes at all. There doesn’t need to be any externally-visible dependency upon libstdc++ at all. Most of the user-facing C++ code for users using the new libtiff C++ interface would be header-only without any library dependencies. Code using e.g. standard library types and containers which are header-only will not bring in any library dependency. Things like std::optional, std::expected, std::array etc. Kind regards, Roger _______________________________________________ Tiff mailing list [email protected] https://lists.osgeo.org/mailman/listinfo/tiff
