Le mar. 30 déc. 2025, à 09 h 50, Roger Leigh via Tiff <[email protected]> a écrit :
> 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. > Not at any stage the but the end goal of modern C++ internals means a mostly complete rewrite. Splitting it out in multiple stages does not change that. It will be almost entirely new code, likely with entirely new bugs. 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.) > Those are reasonable and low risk changes but not what I understood from your issue. There is still the matter of adding C++ as a requirement but that is not a risk of causing bugs, rather a risk of leaving a lot of old platforms behind. > * 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. > This is something we should have had ages ago but it is almost entirely unrelated to the implementation language. The only link is that we'll likely need some new safer (non vararg) C APIs and it might be easier to do those with cleaner code inside. 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. > If 90% of the code gets refactored into a different language with idioms from a different century, I call it a rewrite :-) It's just not from scratch. But there will be a lot more new code than old code from what I understand. > 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 > Not familiar with these but does C++ ever count as safe? Granted, it's somewhat easier to write good code but it still has an awful lot of ways to shoot yourself in the foot. > 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. > No need to sugar coat it, the code was written before security for image libraries was a thing. It shows. The code of the tools is even worse and seems to be causing many of the bug reports. The thing is, many of its users don't really have security concerns. > 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. > All very good questions. Especially as the current C API has some fundamentally unsafe parts which may remain a risk as long as we carry them. A case could be made that it should be deprecated or maintained as a separate "unsafe" project and projects which care about security should only use newer APIs. 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. > For what it's worth, I think a safe API should come first. It will take the longest to be adopted as it requires people to change their code. I'm not familiar enough with Rust to know which way is the more sensible to get there or if we even should. Another thing to consider is it will likely shrink the pool of contributors compared to C++. More is not always better but libtiff has never exactly had an abundance of volunteers. Olivier
_______________________________________________ Tiff mailing list [email protected] https://lists.osgeo.org/mailman/listinfo/tiff
