> > Is option 3) worth investigating?
It seems like the best solution in current circumstances. Another solution could be to eliminate all recursion but thread_local recursion counter is simpler to do. > #else > // fallback to process global recursion count – overcounts depth if > PDFs processed in parallel on multiple threads, same result as thread_local > if process single threaded > #define PODOFO_THREAD_LOCAL > #endif But this fallback would cause UB unless all access to t_nRecursionDepth is atomic or guarded by mutex. > In a release build on x86/x64 each recursive ReadArray call loop uses > about 400 bytes of stack. > - Windows IIS 32-bit worker processes – 256 KB max stack (stack > overflows with 655 ‘[‘ characters) > > So would the limit of 500 as default be enough? It should be far enough from value which would cause stack overflow. I had a look at the patch in > https://sourceforge.net/p/podofo/tickets/25/#51b9. That’s a simpler > solution than the changes I proposed for PdfRecursionGuard. > That patch introduces UB (same reason as above).
_______________________________________________ Podofo-users mailing list Podofo-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/podofo-users
