Late last night I was able to get though a build and do a bit of testing with the code from yesterday's trunk.
It seemed to worked fine. Using a Microsoft compiler and building for (non-debug) release mode optimized for speed (/O2) it showed: Compiled with 8-bit support only UTF-8 support No Unicode properties support No just-in-time compiler support Newline sequence is LF \R matches all Unicode newlines Internal link size = 2 POSIX malloc threshold = 30 Default match limit = 50000 Default recursion depth limit = 2500 Match recursion uses stack: frame size = 340 bytes (The POSIX threshold, match limit, and recursion depth shown above are non-standard values that I overrode in my config.h) The "340 bytes" result matches what I was getting with the patch, minus accounting for those 2 extra ints. ====== Compiling the PCRE library instead for debug mode (/Od) shows: Match recursion uses stack: frame size = 940 bytes 940 is the correct value and "normal" behavior in that situation. A compiler's debug mode will not optimize the sequence of storage for better alignment, and it often puts variables at a gross alignment. Obviously this causes code built for debug to get a stack fault much sooner in a recursive process than a compiler's optimized code. I touched on this briefly in a pre-dev reply about Bug# 1180 on Nov 28: > Also be careful of the stack when using a version built for debug. > Disabling optimization with /Od may have a profound impact on stack > requirements. I've seen the recursive PCRE match() function use much > more than twice its normal stack with /Od vs. having /O1 or /O2. It's > not unique to PCRE, it may be the way MSVC initially assigns default > alignment. To me this adds weight to trying to have this method to calculate the stack requirement as it truly exists at run-time. I'm guessing you're compiling gcc with debug and not for release mode, and that's why the values you're seeing are unexpected. Hopefully you will see a more sane and consistent result with an optimized compile vs. debug. ====== (PS) I had some difficulty building pcretest. Paragraph (10) of NON-UNIX-USE now mentions it needs to be linked with pcre_printint, (different from 8.21) but even doing that yielded unresolved externals. pcre_printint.obj : error LNK2001: unresolved external symbol __pcre_OP_lengths pcre_printint.obj : error LNK2001: unresolved external symbol __pcre_utf8_table3 pcre_printint.obj : error LNK2001: unresolved external symbol __pcre_utf8_table4 pcretest.exe : fatal error LNK1120: 3 unresolved externals It turns out that pcretest also needed to be linked with pcre_tables. Unless I did something wrong in my hand-crafted build, mention of that may be needed in the NON-UNIX-USE document. ====== Today I'm going to try the current version in the latest trunk having your new set of modifications. Regards, Graycode -- ## List details at https://lists.exim.org/mailman/listinfo/pcre-dev
