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
