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

On 30.08.2013 11:24, ph10@??? wrote:

>> I would prefer option B or C as it frees applications from figuring
>> out the correct memory size of ovector.
>
> I don't understand your comment ... the size is given explicitly for
> both B and C, so the application must give it.

Both A, B, and C must give the vector_size.

But for A, the caller must also supply the ovector memory. This means
that the caller must calculate vector_size * sizeof(size_t) and allocate
accordingly. Not a big deal, but a slight chance to introduce errors if
done incorrectly.

For B and C, this calculation is done by PCRE. And I expect PCRE to do
this more reliably and allocate exactly the amount of memory needed.

In other word: Memory used by PCRE is allocated by PCRE and not
elsewhere. So B and C avoid a potential source for memory errors like
memory overruns which are difficult to debug.

> (If an application
> wants to get a precise size for ovector, it can use an info call to
> find out the highest capture number, but many applications that are
> processing more than one regex just allocate a largish ovector and
> use it for all of them.)

Maybe a negative vector_size could handle the highest capture number
automatically, like

pcre2_create_match_data(context, -1);

My idea is to move complexity from applications into PCRE where it is
easier to handle and better tested.

Ralf