GNU bug report logs - #47264
RFE: pcre2 support

Previous Next

Full log

View this message in rfc822 format

From: Carlo Marcelo Arenas Belón <carenas <at> gmail.com>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: Jaroslav Skarvada <jskarvad <at> redhat.com>, 47264 <at> debbugs.gnu.org
Subject: bug#47264: [PATCH v2] pcre: migrate to pcre2
Date: Mon, 15 Nov 2021 12:49:17 -0800

[Message part 1 (text/plain, inline)]

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

[0001-pcre-avoid-using-SIZE_MAX.patch (text/plain, attachment)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.