On Mon, 15 Jun 2015, Petr Pisar wrote: > My proposal was to to measure number of consumed stack. Instead of adding > 1 to a counter on each call, one would compute difference of stack pointer at > current call to the first call and compared this delta to the limit. You could > do it even without in-line assembler simply by referencing an > automatic-storage variable like a variable local to the current function. Of > course there would be some off-by-one-call drift but that could be ignored or > extrapolated based on current stack usage growth ratio.
That approach assumes a contiguous stack. I see that gcc 4.6.0 implements split stack functionality. I wouldn't want to rely on comparing addresses of automatic variables. > Your remark gave me an idea that the size of the stack could be obtained by > getrlimit() on the first call, so even the user would not need to specify the > limit explicitly as the default would be that (minus stack consumed by a PCRE > application on the first call). That would provide fully automatic heuristic > preventing from unexpected sefgaults. PCRE was written in standard C (it was C90 in those days); PCRE2 does use a few things from C99. However, getrlimit() is not a standard C function, so it cannot be used in the main library code. It *is* used in pcre2test, but only for those OS that support it. I don't want to start putting OS-specific things into the library code. I am sorry to be so negative! Note that pcre2_compile() has a callout feature for checking available stack (see pcre2_set_compile_recursion_guard()). I suppose something similar could be added to pcre2_match, but it would seriously affect performance and also requires the calling program to cooperate. Philip -- Philip Hazel -- ## List details at https://lists.exim.org/mailman/listinfo/pcre-dev
