Re: [pcre-dev] Proposal for a new API for PCRE

Page principale
Supprimer ce message
Auteur: Ralf Junker
Date:  
À: pcre-dev
Sujet: Re: [pcre-dev] Proposal for a new API for PCRE
> By default, PCRE is compiled to use the system stack for recursive
> function calls when matching patterns using the interpreter (not JIT)
> with pcre2_exec(). In some environments, where the size of this stack
> is limited, PCRE is often compiled to use heap storage instead. The
> memory blocks that are used for this purpose are all the same size,


Are these memory block all the same size for ONE individual pattern or
for ALL different patterns as well? I realize they might change between
different PCRE versions.

> and are requested and freed in last-out-first-in order. A private
> memory manager could implement this kind of usage more efficiently
> than the general case; to make this possible, two further memory
> management functions can be added to a context:
>
> pcre2_set_recursion_memory_management(context,
> private_recursion_malloc, private_recursion_free);


Would it be useful to add private_recursion_begin() and
private_recursion_end() callbacks so that

a) Applications can initialize their recursion memory manger and

b) optionally cleanup after matching

> Question 1: I haven’t specified a function for reading memory
> management or callout functions. Are these necessary? The only use I
> can think of is for saving and restoring a context, but this can be
> done by making a copy of the whole context.
>
> Question 2: In fact, do we really need these ‘get’ functions at all?
> An application can easily remember what it has set in a context if
> it needs to.


I would appreciate 'get' functions for ALL properties. Reasons:

a) Simplifies object wrapper code.

   b) Requires less memory for those objects
      because settings do not have to be stored twice.


> 8 Matching functions


I would prefer option B or C as it frees applications from figuring out
the correct memory size of ovector. The memory is then also maintained
by the pcre2_match_data and automatically freed if that structure is
destroyed. All in all, less work for applications and less options for
mistakes.

Ralf