Hi
I think there are a couple of options here:
Option 1)
Make C++11 a requirement only when PoDoFo is compiled with PODOFO_MULTI_THREAD.
That means the change won’t affect users who compile PoDoFo single threaded
So the recursion guard definition would look something like this:
#if !defined(PODOFO_MULTI_THREAD)
static int s_nRecursionDepth; // PoDoFo is single threaded
#elif defined(thread_local)
static int thread_local s_nRecursionDepth; // PoDoFo has threading support
and using C++11 compiler
#else
#error C++11 thread_local is required for multi-thread
#endif
The thread_local macro is available in
GCC 4.8.0 and later (4.8.0 was released 2013)
clang 3.3 and later (3.3 was released 2013)
clang (macOS fork) (available in XCode 8, which was released in 2016)
Visual Studio 2015 and later
Option 2)
Another option is adding a fallback for very old compilers that uses mutexes.
This mutex fallback won’t be used by many people (because most will use modern
compilers that support C++11) but might make it easier to agree on a patch (and
isn’t hard to implement). It would look something like this:
#if !defined(PODOFO_MULTI_THREAD)
static int s_nRecursionDepth; // PoDoFo is single threaded
#eif defined(thread_local)
static int thread_local s_nRecursionDepth; // PoDoFo has threading support
and using C++11 compiler
#else
static Util::PdfMutex s_guardMutex;
static int s_nRecursionDepth; // PoDoFo is multi threaded and this needs
protected by a mutex
#endif
PdfRecursionGuard ::~PdfRecursionGuard()
{
#if !defined(PODOFO_MULTI_THREAD)
--s_nRecursionDepth; // PoDoFo is single threaded
#elif defined(thread_local)
--s_nRecursionDepth; // PoDoFo has threading support but this is thread_local
#else
PdfMutexWrapper lock(s_guardMutex);
--s_nRecursionDepth; // PoDoFo is multi threaded and this needs protected by
a mutex
#endif
}
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 07:45
To: Michal Sudolsky <sudols...@gmail.com>, "PowerMapper.com"
<mark.rog...@powermapper.com>
Cc: "podofo-users@lists.sourceforge.net" <podofo-users@lists.sourceforge.net>
Subject: RE: [Podofo-users] PoDoFo and recursive stack consumption CVEs
From: Michal Sudolsky sudols...@gmail.com<mailto:sudols...@gmail.com>
> But this fallback would cause UB unless all access to t_nRecursionDepth is
> atomic or guarded by mutex.
If we want to avoid UB in the multithreaded world, I’m afraid we will have to
make a C++11 compiler a requirement, as C++03 never acknowledged the existence
of threads. (That is not limited to this place, a lot of methods like
PdfEncodingFactory::GlobalPdfRomanEncodingInstance are not currently threadsafe
in C++03, as discussed earlier.)
Now, if we do that, the solution is easy, make the variables used with the
recursion guard thread_local. (Atomic or mutex are not a good solution, as
those would make the recursion guard depend on what other threads are doing at
the same time.)
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
