>Do we agree this would implement different functionality, with the potential >of hard to debug sporadic effects depending on how the threads actually run? > Yes, although this already happens with PoDoFo – all the PoDoFo mutex methods are defined as no-ops unless PODOFO_MULTI_THREAD is defined.
Personally, I’d be much happier if PoDoFo only supported modern compilers, but it’s hard to know which compilers people actually use (especially for embedded systems). One of the reasons for the PdfMM fork was the inability to use modern C++ in PoDoFo. I don’t think it’s helpful that PoDoFo supports very old compilers like Visual C++ 6 and Visual Studio 2005 with known security vulnerabilities (VS 2005 reached end of life in 2016 and no longer receives security updates). Shipping code built using a complier containing unpatched security vulnerabilities is fundamentally unsafe. Even testing the build system still works with old compilers is potentially dangerous. Only supporting compilers that still get security updates is a simple way to get rid of old compilers, and easy to justify. > These compilers may or may not implement thread_local as macros,. I think the standard says it’s a macro: https://en.cppreference.com/w/c/thread/thread_local Best Regards Mark Mark Rogers - mark.rog...@powermapper.com PowerMapper Software Ltd - www.powermapper.com Registered in Scotland No 362274 Quartermile 2 Edinburgh EH3 9GL From: Christopher Creutzig <ccreu...@mathworks.com> Date: Monday, 22 November 2021 at 12:53 To: "podofo-users@lists.sourceforge.net" <podofo-users@lists.sourceforge.net> Subject: Re: [Podofo-users] PoDoFo and recursive stack consumption CVEs > The thread_local macro is available in These compilers may or may not implement thread_local as macros, but technically, it is a C++ keyword, and we should not use ifdef(thread_local). I think #if __cplusplus >= 201103L would be a more robust option. > Another option is adding a fallback for very old compilers that uses mutexes. Do we agree this would implement different functionality, with the potential of hard to debug sporadic effects depending on how the threads actually run? I think something like the following is more promising: #if __cplusplus >= 201103L || defined(thread_local) # define PODOFO_THREAD_LOCAL thread_local #else # ifdef _MSC_VER # define PODOFO_THREAD_LOCAL __declspec(thread) # elif defined(__GNUC__) # define PODOFO_THREAD_LOCAL __thread # else # error "Unknown old compiler, please add thread local support" # endif #endif Cheers, Christopher The MathWorks GmbH | Friedlandstr.18 | 52064 Aachen | District Court Aachen | HRB 8082 | Managing Directors: Bertrand Dissler, Steven D. Barbo, Jeanne O’Keefe
_______________________________________________ Podofo-users mailing list Podofo-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/podofo-users
