------- You are receiving this mail because: -------
You are on the CC list for the bug.
http://bugs.exim.org/show_bug.cgi?id=1121
--- Comment #8 from Philip Hazel <ph10@???> 2011-06-13 17:37:24 ---
On Mon, 13 Jun 2011, Petr Pisar wrote:
> Just for clarification: ABI depends e.g. on a size of public data structures,
> so having following code in public pcre header file:
>
> struct dst {
> #ifdef STACK_IMPLEMENTATION
> int foo;
> #else
> long int foo;
> #endif
> int bar;
> };
>
> would break ABI as application compiled against one version would assume
> different size of foo and struct dst or different offset of bar.
There is no difference in the public header file. The NO_RECURSE macro,
which controls this, is defined (or not defined) in config.h. It is
tested only in pcre_exec.c.
> If you wonder why somebody wants slower heap variant, it's because the heap
> one can be limited on memory size whereas the stack one on recursion level
> only. And if user has a public service that operates on unknown input, a bad
> guy could supply such input the stack implementation would crash while heap
> variant would refuse processing gracefully. (There is unkown relation between
> recursion depth and consumed stack size.)
There are some comments about the relationship between recursion depth
and stack size in the pcrestack.3 man page, where it says:
As a very rough rule of thumb, you should reckon on about 500 bytes
per recursion. Thus, if you want to limit your stack usage to 8Mb, you
should set the limit at 16000 recursions. A 64Mb stack, on the other
hand, can support around 128000 recursions.
If somebody is worried about crashes on unknown data, another approach
is to set a trap to catch the signal before calling pcre_exec().
Philip
--
Configure bugmail:
http://bugs.exim.org/userprefs.cgi?tab=email
