Re: [pcre-dev] bug#60690: [PATCH v2] grep: correctly identify utf-8 characters with \{b, w} in -P

On Mon, Jan 09 2023, Paul Eggert wrote: > On 1/9/23 03:35, Ævar Arnfjörð Bjarmason wrote: > >> You almost never want "everything Unicode considers a digit", and if you >> do using e.g. \p{Nd} instead of \d would be better in terms of >> expressing your intent. > > For GNU grep, PCRE2_UCP is

Re: [pcre-dev] [PATCH v2] grep: correctly identify utf-8 characters with \{b, w} in -P

On Sun, Jan 08 2023, Carlo Marcelo Arenas Belón wrote: > When UTF is enabled for a PCRE match, the corresponding flags are > added to the pcre2_compile() call, but PCRE2_UCP wasn't included. > > This prevents extending the meaning of the character classes to > include those new valid characters

Re: [pcre-dev] [PATCH] grep: fall back to interpreter mode if JIT fails

On Fri, Dec 16 2022, Carlo Arenas wrote: [CC-ing pcre-dev@ for this "future error API" discussion] > On Fri, Dec 16, 2022 at 3:09 PM Junio C Hamano wrote: >> >> Mathias Krause writes: >> >> > ... However, from a user's point of view a fall back to >> > interpreter mode might still be desired

Re: [pcre-dev] [RFC PATCH 1/2] grep: fallback to interpreter if JIT fails with pcre1

On Tue, Dec 11 2018, Carlo Arenas wrote: > On Mon, Dec 10, 2018 at 12:24 AM Ævar Arnfjörð Bjarmason > wrote: >> On Mon, Dec 10 2018, brian m. carlson wrote: >> > Considering that some Linux users use PaX kernels with standard >> > distributions and that most BSD kernels can be custom-compiled

Re: [pcre-dev] [RFC PATCH 1/2] grep: fallback to interpreter if JIT fails with pcre1

On Mon, Dec 10 2018, brian m. carlson wrote: > On Mon, Dec 10, 2018 at 12:51:01AM +0100, Ævar Arnfjörð Bjarmason wrote: >> Obviously this & what you have in 2/2 needs to be fixed in some way. >> >> Is the issue on SELinux, OpenBSD, NetBSD etc. *how* PCRE is creating the >> the JIT'd code? I.e.

Re: [pcre-dev] [RFC PATCH 1/2] grep: fallback to interpreter if JIT fails with pcre1

On Sun, Dec 09 2018, Carlo Marcelo Arenas Belón wrote: [+CC pcre-dev] > JIT support was added to 8.20 but the interface we rely on is only > enabled after 8.32 so try to make the message clearer. > > in systems where there are restrictions against creating executable > pages programatically

Re: [pcre-dev] PCRE2 10.31-RC1 Release Candidate

On Sat, Jan 13, 2018 at 5:57 PM, wrote: > I have just put the Release Candidate for 10.31 in the usual place: > > ftp://ftp.csx.cam.ac.uk/pub/software/programming/pcre/Testing/pcre2-10.31-RC1.tar.gz >

Re: [pcre-dev] Extracting trigrams from PCRE syntax

On Tue, Nov 28, 2017 at 6:42 PM, wrote: > On Mon, 27 Nov 2017, I wrote: > >> I suppose one might consider providing a function similar to >> pcre2_callout_enumerate(), which enumerates the callouts in a compiled >> pattern. Something like pcre2_fixed_strings_enumerate()

[pcre-dev] Extracting trigrams from PCRE syntax

One of the pie-in-the-sky ideas I have for PCRE use in Git is to start pre-indexing regular expressions. This method is covered in this paper/blog post: https://swtch.com/~rsc/regexp/regexp4.html Basically, consider a regex like: foox.*(bary|bazz) It can be broken into a trigram tree like:

Re: [pcre-dev] How am I supposed to use PCRE2 JIT in the face of (*NO_JIT) ?

#1 as well? A pedantic reading of the manpage would probably suggest so, but I can't see how the JIT compiled size would ever be zero without JIT being disabled... > Philip, your opinion? > > Regards, > Zoltan > > Eredeti levél > Feladó: Ævar Arnfjörð Bjarmason

[pcre-dev] How am I supposed to use PCRE2 JIT in the face of (*NO_JIT) ?

I'm doing the following: 1. pcre2_compile 2. pcre2_config(...CONFIG_JIT 3. pcre2_pattern_info(...INFO_JITSIZE...) Then if the JIT is on according to the pcre2_config() return value, call pcre2_jit_match() later instead of pcre2_match() (and earlier jit_compile, jit stack etc.). The problem

[pcre-dev] Git 2.14.0 released with PCRE 2 support

Git 2.14.0 got released last week with release notes that recommend using pcre2 instead of pcre1: https://github.com/git/git/blob/master/Documentation/RelNotes/2.14.0.txt#L25 I've already seen e.g. Debian, Arch and Fedora change their dependency from pcre1 to pcre2 for Git. Since a lot of

Re: [pcre-dev] PCRE1 8.41-RC1 test release

On Tue, Jun 13, 2017 at 6:59 PM, wrote: > I have just put the 8.41-RC1 tarballs in the usual place: > > ftp://ftp.csx.cam.ac.uk/pub/software/programming/pcre/Testing/pcre-8.41-RC1.tar.gz > ftp://ftp.csx.cam.ac.uk/pub/software/programming/pcre/Testing/pcre-8.41-RC1.tar.bz2

Re: [pcre-dev] How do I support pcre1 JIT on all versions?

On Thu, Jun 1, 2017 at 5:50 AM, Zoltán Herczeg wrote: > I would simply use the PCRE version number to detect jit_exec at compile > time: > > #if (PCRE_MAJOR > 8 || (PCRE_MAJOR == 8 && PCRE_MINOR >= 32)) > #define PCRE_JIT_EXEC_AVAILABLE > #endif That'll only work if pcre

[pcre-dev] How do I support pcre1 JIT on all versions?

My patch to add JIT support to Git with the PCRE v1 API works all the way down to PCRE version 7.5 (the last one I could get to compile), but *only* if I compile the versions that support JIT with --enable-jit, not --disable-jit. The problem is that both PCRE_CONFIG_JIT and PCRE_STUDY_JIT_COMPILE

Re: [pcre-dev] [Bug 2124] Regular expression causes endless? looping in pcre2_match_8

On Tue, May 23, 2017 at 6:32 PM, wrote: > https://bugs.exim.org/show_bug.cgi?id=2124 > > --- Comment #3 from Philip Hazel --- > A non-plain file is fine, but my version of unzip doesn't like it: > > $ unzip crash_clamav_pcre.docx.zip > Archive:

Re: [pcre-dev] Are there any examples of minimal embedded pcre (v2)?

On Sat, May 6, 2017 at 7:33 PM, <p...@hermes.cam.ac.uk> wrote: > On Fri, 5 May 2017, Ævar Arnfjörð Bjarmason via Pcre-dev wrote: > >> I'm looking into copying the pcre v2 sources into git.git as a way to >> appease people that mind the dependency, i.e. having to packa

[pcre-dev] Are there any examples of minimal embedded pcre (v2)?

I'm looking into copying the pcre v2 sources into git.git as a way to appease people that mind the dependency, i.e. having to package pcre v2 themselves. They could then build with GIMME_YOUR_LIBPCRE2=Y or something. I haven't started this but was hoping to find some minimal example of a project

Re: [pcre-dev] I'm adding PCRE v2 support to Git. It's a bit slower than v1

On Tue, Apr 18, 2017 at 10:09 AM, Zoltán Herczeg wrote: I.e. no difference in v1 & v2 anymore. The log case though shows pcre1 being 2% faster than pcre2: > > I don't know the reason then, needs more investigation. Btw I have started to > improve the first character

Re: [pcre-dev] I'm adding PCRE v2 support to Git. It's a bit slower than v1

On Thu, Apr 13, 2017 at 8:51 AM, Zoltán Herczeg wrote: > Hi, > I did some basic performance benchmarks between v1 and v2 of PCRE. Depending on whether we use git-grep or git-log v2 is 1% to 10% slower than v1 when both use JIT. >>> >>> I would like to see the

Re: [pcre-dev] I'm adding PCRE v2 support to Git. It's a bit slower than v1

On Mon, Apr 10, 2017 at 4:13 PM, Zoltán Herczeg wrote: > Hi Ævar, > > this is really awesome news! I am happy that you choose pcre for git. > >>I did some basic performance benchmarks between v1 and v2 of PCRE. >>Depending on whether we use git-grep or git-log v2 is 1% to

Re: [pcre-dev] I'm adding PCRE v2 support to Git. It's a bit slower than v1

On Mon, Apr 10, 2017 at 4:13 PM, Zoltán Herczeg wrote: > Hi Ævar, > > this is really awesome news! I am happy that you choose pcre for git. > >>I did some basic performance benchmarks between v1 and v2 of PCRE. >>Depending on whether we use git-grep or git-log v2 is 1% to