Hi Sheri,
if I understand you correctly, you have a binary program that you cannot change. However, you can recompile the pcre lib for this program. In that case you could just change pcreposix.c a little:
typedef struct {
void *re_pcre;
size_t re_nsub;
size_t re_erroffset;
} regex_t;
You can freely change the regcomp() function to do the study and internally allocate a struct with two pointer fields, one for pcre and the other for study data. And change the other functions as well to expect this stuct not a direct pointer to the pcre pattern in re_pcre field, and do accordingly.
Regards,
Zoltan
Philip Hazel <ph10@???> írta:
>On Wed, 16 Nov 2011, Sheri wrote:>
>
> Here's a minimal request, please let me know if feasible.>
> >
> Suppose you added a regexec2 to the POSIX interface which passed study data>
> instead of NULL to pcre_exec. Couldn't the native pcre_study be used to create>
> study data based on the compiled pattern that was regcomp'ed? Mixed interface>
> for our older "global" regex'es?>
>
Performance would be poor because every time you called regexec2, it >
would have to do the study and the free ... and JIT study takes>
appreciative resources. So unless you only ever match a pattern exactly>
once, the performance gain might (would?) not be much, if anything. We>
already know that for relatively simple patterns matched once, JIT is>
not worth using. It comes into its own when you can do *one* JIT study,>
followed by *many* calls to pcre_exec.>
>
OK, now you are going to say why not do the study outside regexec, based >
on the POSIX data structure generated by regcomp (i.e. invent regstudy).>
If you do that, you have to pass it to regexec2 somehow ... this is>
changing your code quite a lot: adding a call to regstudy, modifying>
the regexec calls. I would argue that this is almost as much work as>
changing to the native API.>
>
I appreciate your situation, not a nice place to be in.>
>
Philip>
>
-- >
Philip Hazel>
>
-- >
## List details at
https://lists.exim.org/mailman/listinfo/pcre-dev >
