Re: [pcre-dev] API types in PCRE2 and minor documentation ch…

Top Page
Delete this message
Author: ph10
Date:  
To: Maël Hörz
CC: pcre-dev
Subject: Re: [pcre-dev] API types in PCRE2 and minor documentation change suggestion
On Sun, 30 Nov 2014, Maël Hörz wrote:

> pcre2_get_ovector_count returns a uint32_t and callout_number is uint32_t, but
> the number parameter for the following functions is unsigned int:
>
> pcre2_substring_copy_bynumber
> pcre2_substring_get_bynumber
> pcre2_substring_length_bynumber
>
> Shouldn't that be the same types?


Yes, for consistency I'll change them to uint32_t.

> int pcre2_dfa_match(const pcre2_code *code, PCRE2_SPTR subject, PCRE2_SIZE
> length, PCRE2_SIZE startoffset, uint32_t options, pcre2_match_data
> *match_data, pcre2_match_context *mcontext, int *workspace, PCRE2_SIZE
> wscount);
>
>
>   workspace    Points to a vector of ints used as working space
>   wscount      Number of elements in the vector

>
> Are ints always enough? I am not familiar enough with the code to know what
> constraints there might be that are related to match positions/ovectors etc.


The values in the vector are positive and negative numbers (with
different meanings). Some of them are offsets, but they are offsets into
the compiled pattern, not into the subject. By default, the length of a
compiled pattern is constrained by LINK_SIZE=2, which means there is no
problem there, nor with LINK_SIZE=3. The only possible problem would be
with a version of PCRE2 that was compiled with LINK_SIZE=4 and an
absolutely enormous pattern - I really do not think this is likely.

> pcre2_pattern_info man page:
> I would reorder the information a little, I got confused reading it the first
> time.


Thanks for the comment. I'll work on it.

Philip

--
Philip Hazel