On Wed, 15 Jul 2009, xgl001 wrote:
> Something I would like to see in future PCRE is an API call to
> establish run-time settings per the calling program.
If someone send me some suggested code, I would look at it.
> For some complicated expressions, the code may have previously
> invoked pcre_study() which may produce its own pcre_extra.
> In that case the recursion limit needs to be assigned to that
> other pcre_extra when it's available.
>
> That's a bit cumbersome. It would be handy to have a "standard"
> PCRE API function that could be called at start-up or whenever
> the program wanted to change its limit of MATCH_LIMIT_RECURSION,
> MATCH_LIMIT, and perhaps any other run-time settings that could
> be stored as internal global variables within PCRE.
I would definitely NOT want to have any more internal global variables.
PCRE doesn't remember information (except for the malloc/free
vectors, and with hindsight, I would have done that differently as
well). The main reason is so that PCRE can be thread-safe.
Some thought would be needed to create some kind of new structure that
could be passed into the pcre functions - and of course new calls would
be needed, which would complicate things....
I can't say that I'm very enthusiastic at this stage. Sorry about that.
I realize that the current state is not ideal.
Hmm. Maybe some new function that manages "remembering" in a passed-in
structure, and which then does the "cumbersome" stuff you talk about
above before calling the base functions. In other words, some kind of
wrapper that would leave the underlying functions alone.
> That new API might also be a good choice for an application to
> specify the pcre_malloc and pcre_free vectors when it chooses to
> use its own methods for those. By the way, I think those are a
> fantastic feature.
Indeed, though they lack a "user data" parameter, as has been pointed
out.
