------- You are receiving this mail because: -------
You are on the CC list for the bug.
http://bugs.exim.org/show_bug.cgi?id=869
Philip Hazel <ph10@???> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|REOPENED |RESOLVED
Resolution| |WONTFIX
--- Comment #3 from Philip Hazel <ph10@???> 2009-08-02 11:29:09 ---
You can compile PCRE to use the heap instead of the stack for recursion if you
want to (i.e. your solution (2)). This is all described in the various
documentation files about building PCRE. A number of Windows users do this,
because the stack seems to be normally smaller in Windows. However, PCRE runs
more slowly when compiled in this way because it has to manage the memory
itself.
The data that has to be remembered when recursion is used has to be remembered
somewhere. When I wrote PCRE (and remember, I'm a Unix/Linux person; I know
absolutely nothing about Windows), it seemed to me that the mechanism for
calling functions and saving data on the stack would be carefully implemented
and optimised, so it seemed sensible to use it. I have to confess that I came
from a background where stacks could expand as much as necessary, taking more
memory from the heap as they needed it.
It is always going to be possible to write a regular expression that, when
searched using an NFA algorithm (that is, depth first), will run out of however
much memory you give it for saving backtracking points. At least, that's what I
believe to be the case. So there will always be the possibility of a failure
return of the kind "ran out of resources for this match". The calling program
must deal with this. This is true whether the stack or the heap is used.
It is certainly far too late in the life of PCRE to rewrite in some other way;
as stated above, you can alread choose between using the stack or the heap for
"recursion memory". I am going to close this again as "wontfix"; you are
welcome, of course, to re-reopen it, in which case I'll leave it open - but I
have to say I won't be doing anything about it.
--
Configure bugmail:
http://bugs.exim.org/userprefs.cgi?tab=email
