On Fri, 20 Jan 2012, Graycode wrote:

> The "340 bytes" result matches what I was getting with the patch, minus
> accounting for those 2 extra ints.

Good!

> I'm guessing you're compiling gcc with debug and not for release mode,

I was, and I figured that out last night. Turning off debug does change 
the value with gcc, as does changing the optimization.

> pcretest.exe : fatal error LNK1120: 3 unresolved externals
> 
> It turns out that pcretest also needed to be linked with pcre_tables.

Thanks for the note, but I don't understand the problem, because
pcre_tables should be linked as part of the PCRE library which you link
pcretest with.

> Unless I did something wrong in my hand-crafted build, mention of that
> may be needed in the NON-UNIX-USE document.

Perhaps you left pcre_tables out of the library build?

> This version also seems fine.  With my normal MSVC build it shows:

Also good!

> This new stack calculation may provide a reasonably
> accurate estimate of where to set the match_limit_recursion such that
> there is a meaningful PCRE error code instead of dying out with a
> stack fault.

That's what I'm hoping. I will add some documentation now that I know it 
seems to be working.

> If you get to a point where you feel having the stack calculation
> introduces complexity or otherwise becomes un-maintainable, then I'm
> OK with going back to hacking something into new PCRE releases for my
> own uses.  

I've ended up with a pretty small patch, so I think it's OK to leave it
in.

Philip

-- 
Philip Hazel

-- 
## List details at https://lists.exim.org/mailman/listinfo/pcre-dev 

Reply via email to