Hi,
I would not change the ABI of PCRE at the moment. I want this fast path for JIT as a drop in replacement for pcre_exec. However, I agree to add the regex as the first (although unused) parameter. If noone objects, I will land this.
Regards,
Zoltan
Philip Hazel <ph10@???> írta:
>On Sun, 30 Sep 2012, Giuseppe D'Angelo wrote:>
>
> It would probably be the best to use opaque pointers. This way, you>
> can change its memory layout at any time (f.i. adding new fields)>
> without breaking ABI compatibility and without having to allocate>
> extra memory in a (opaque?) pointer inside the pcre_context structure.>
> One could either request one to be allocated by PCRE, or invoke a PCRE>
> function to know the size in bytes of the structure, size to be passed>
> to malloc or a custom allocation routine.>
>
I don't think the ABI compatibility is an issue: just like the existing >
pcre_extra block, it can be documented that the order of the fields in >
the structure is not fixed and may change between releases. However,>
that's a small point.>
>
More importantly, using an opaque pointer means that functions will have >
to be supplied to set and read the values in the structure's fields. As >
there will be more than one type (pointers, ints, etc) there would have >
to be either:>
>
(1) A single function using a (void *) argument to get/set values; or>
(2) Different functions for different data types.>
>
I feel this gets quite clumsy. For example, two of the fields will be>
match_limit and match_limit_recursion. Setting them using (1) would need >
code like this:>
>
long int match_limit = 10000;>
long int match_limit_recursion = 5000;>
pcre_set_context(pc, PCRE_CONTEXT_MATCH_LIMIT, &match_limit);>
pcre_set_context(pc, PCRE_CONTEXT_MATCH_LIMIT_RECURSION, &match_limit_recursion);>
>
Or, using (2):>
>
pcre_set_context_long_int(pc, PCRE_CONTEXT_MATCH_LIMIT, 10000);>
pcre_set_context_long_int(pc, PCRE_CONTEXT_MATCH_LIMIT_RECURSION, 5000);>
>
with several other functions for other types of value. Reading the>
values would require an equivalent set of functions.>
>
Isn't it much neater to let the user write>
>
pc->match_limit = 10000;>
pc->match_limit_recursion = 5000;>
>
and read their values similarly? Note that this proposal does not >
replace pcre_extra: that would still be returned by pcre_study(), but it >
would contain only opaque study and JIT data. Indeed pcre_extra could >
become totally opaque (as it was in the original PCRE).>
>
We could insist in the API that pcre_init_context() *must* always be>
called before setting any values. This would ensure that any new fields>
in a new release were suitably initialized with defaults.>
>
But this is just my view...>
>
Philip>
>
-- >
Philip Hazel>
>
-- >
## List details at
https://lists.exim.org/mailman/listinfo/pcre-dev >
