On 29 Dec 2025, at 16:43, Olivier Paquet <[email protected]> wrote: > I find the proposal's categorization of "let's build this as C++" as low risk > bordering on ridiculous. It will break stuff on some platforms, that's for > certain. The rest of it looks more or less like "let's rewrite everything".
It very much was not intended to read this way. I intend the approach to be a measured, incremental series of refactors with no “rewriting the world” at any stage. We would need to plan each stage out properly, but the initial stages would be something along the lines of: * Make the existing C codebase compile cleanly with a C++ compiler. This is already done. For example see https://gitlab.com/libtiff/libtiff/-/jobs/12552031204. Done For GCC and Clang; MSVC is already C++. No problems, all tools and tests compile, all tests pass. * Rename the C sources to C++. No code changes. No ABI changes. * Change TIFF structure to class; migrate free functions to class methods. Actual method contents are unchanged. Retain free functions and call class methods for C compatibility. * Repeat for other types (Directory, Codec etc.) * Type-safe C++ field and pixel data access are header-only inline templates, which ultimately call into the existing unsafe code. It’s all layered on top. There’s obviously more detail than this in practice, but at no point am I proposing a blanket rewrite of *anything*. It’s a sequence of refactors and additions, with the C API and ABI being kept functional and stable at every step. > 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. > > That's the discussion we need to have before any of the more technical > aspects of this. There's no way we can move core libtiff to modern C++ as > proposed and retain the wide support libtiff provides. I think even older C++ > would be a stretch. > > There also needs to be a discussion about the value of doing this. What does > it bring that we can't have without it? It will also bring new bugs. Do the > improvements outweigh the problems? Is this true at every point along the way > or only 5-10 years from now? I’ve summarised some of this in my other replies, regarding things it brings that we can’t have currently. On top of this, there are some additional considerations. I’ve mentioned them previously on the list I think. You might have seen the reporting over the last couple of years about CISA and the phasing-out of unsafe code from January 2026 onwards: https://www.cisa.gov/resources-tools/resources/product-security-bad-practices https://www.cisa.gov/sites/default/files/2023-12/The-Case-for-Memory-Safe-Roadmaps-508c.pdf https://www.cisa.gov/news-events/alerts/2025/06/24/new-guidance-released-reducing-memory-related-vulnerabilities Nearly everything I’ve done in this project over the last decade has all been done with an aim of making libtiff safe, robust and portable. We’ve introduced number of things, from the CMake build system, to GitLab CI, which included coverity static analysis and greatly improved our effective portability, particularly to Windows which hadn’t previously had regular testing. It has all helped, up to a point. Libtiff is a higher-quality codebase as a result. But it’s not enough. We have a seemingly endless stream of CVEs and bugs. And it all stems from this being a legacy C codebase which hasn’t had any really serious attempt at fixing the fundamentals. Just look at the changes made here: https://gitlab.com/libtiff/libtiff/-/compare/warning-additions5..61b5551e0c26685000435885c1ba6cf23b92d416?from_project_id=4721645 And this is merely to add in some stricter compiler warnings! I haven’t even gotten started on actual static analysis and finding more serious problems yet. The C++ conversion would aim to remove every single cast. It’s detailed in the plan. The point here isn’t just about the casts. It’s that the codebase quality overall is not at all great, and C the language as well as legacy coding practices and compatibility concerns are a large part of the problem here. The vast majority of the problems causing the CVEs would not occur in other languages, even C++ with its much stricter type conversion rules. While we could no doubt do a lot of work to do stricter static analysis etc, there are diminishing returns and so it’s worth asking the question of is it worth it, and where the breaking point is where it is not. It’s also that the wider world is starting to make hard demands upon software developers regarding software development practices. It’s been coming in earnest since 2023, and 2026 is when the mandates start to begin for real. Whether we like it or not, unsafe code elimination is now being mandated by national bodies in the USA as well as being copied by other countries around the world, and this will preclude a lot of legacy C libraries. And C++, it might be a lot safer than C but it’s still imperfect. If you want to write an application using libtiff, you now need to justify why you’re using a C library and not a safer alternative. And the strictness will increase over time. At some point you won’t be able to justify using an unsafe C library at all. So for me the question is not so much “do we do this”, as “where do we do this”. Do we do it as part of libtiff, and bring the C API along to help service the existing users. Or do we create a separate branch or separate repository in the libtiff group on GitLab and do it there? Or do we split entirely and do it completely independently? Whatever we choose to do, the rest of the world will move on with or without us, and this is the one of the most important points behind this work. Planning to be a part of the future by doing the work to remain relevant in it. So the core thing I’d want out of the discussion is an agreed plan. One possibility would be as proposed, refactor the core to be C++ with a C compatibility layer. But another could be to plan to later iterate on that and then replace the core with Rust, again with a C (and C++) compatibility layer. Or go directly to Rust with a C API [not suggesting we should do this, but bringing it as a possibility]. This would then allow downstream users of libtiff to plan this in and use libtiff with the justification that we’re doing the work to become safe, even if we’re not safe right now. I know this might seem a little out there, and a lot of the readers might be thinking that this is an unnecessary irrelevance that couldn’t possibly affect them. But this has been coming for a long, long while. Governments have become aware of the endless stream of bugs and security vulnerabilities arising from unsafe code, and have decided to take steps to reduce them. Up until now, most of us have been able to do whatever we felt like, but for better or worse this is changing, and these requirements will trickle down as software used by government departments and agencies will have to detail what they use and why. If we want libtiff to continue to be used, we do need to factor this in to our thinking. Kind regards, Roger _______________________________________________ Tiff mailing list [email protected] https://lists.osgeo.org/mailman/listinfo/tiff
