On Mon, Nov 15, 2021 at 08:17:02AM -0800, Paul Eggert wrote:
> On 11/14/21 20:44, Carlo Arenas wrote:
> 
> > > This shouldn't be a problem in practice. Surely PCRE2_SIZE_MAX is for
> > > forward compatibility to a potential future version of PCRE2 that may
> > > define PCRE2_SIZE to be some other type. For PCRE2 10.20 and earlier
> > > PCRE2_SIZE is hardwired to size_t, so there is only one plausible
> > > default for PCRE2_SIZE_MAX, namely SIZE_MAX.
> > 
> > which is why I mention that it will be better to at least document
> > that in a comment, as it was done everywhere else where assumptions
> > made in the pcre library were used.
> 
> What sort of documentation did you have in mind, exactly?

Apologies, I realize it is difficult to talk about code in abstract when
not inlined, but I think it will better addressed by "fixing" it as shown
in the attached patch.

> > Interestingly enough this discussion gave me an idea for a feature in
> > PCRE where that value will be set to something else than SIZE_MAX and
> > that might break grep in a future release if it lands.
> 
> How would it break grep? I'm not following. If a future version of PCRE
> defines PCRE_SIZE_MAX to something other than SIZE_MAX, grep should work
> just fine because it will use what PCRE defines.

only if we always use PCRE2_SIZE_MAX

Carlo