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. Philip -- Philip Hazel -- ## List details at http://lists.exim.org/mailman/listinfo/pcre-dev
