a pretty nice Perl bug, maybe you could report
it to them.
Regards,
Zoltan
Eredeti levél
Feladó: Zoltán Herczeg < hzmes...@freemail.hu (Link ->
mailto:hzmes...@freemail.hu) >
Dátum: 2021 június 6 07:21:30
Tárgy: Re: [pcre-dev] Capture not reset inside recursion
Címzett:
The title is misleading, that feature is a JavaScript thing:
/(?:(a)b|\1)+/ matches aba in Perl, but not in JavaScript.
Anyway it looks like the problem here is ()? clears the capturing bracket in
Perl when the empty case is selected while restores its previous value in PCRE2.
Matching
I have two comments:
The .* matches to an emtpy string, so it can match to the position of "\r" in a
"\r" string. The length of the match is 0, so it does not match to the "\r"
itself.
The PCRE2_DOTALL option allows dot to match to a newline.
Regards,
Zoltan
Eredeti levél
Hi,
in my experiences this is the easiest way to parse expressions:
main-expression = pre-primary-expression primary-expression
post-primary-expression
pre-primary-expression - mostly unary operators, new operator, etc.
primary-expression - identifiers, keywords (e.g. this/true/null),
I remember a pretty serious bug that was fixed in JIT so I recommended an
update to everybody who use JIT.
Regards,
Zoltan
Eredeti levél
Feladó: Philip Hazel via Pcre-dev < pcre-dev@exim.org (Link ->
mailto:pcre-dev@exim.org) >
Dátum: 2020 december 4 15:42:30
Tárgy:
> However, it is surprising that JIT times grow linearly with subject
> length, whereas the interpreter's grow exponentially.
I posted a link which explains the reason of the difference. The /aa.*?bba/ is
converted to /aa.*?(*SKIP)bba/ internally, and the latter can be executed in
linear time.
Hi,
is this measured with JIT enabled? I wrote an introduction about the JIT
compiler before:
https://zherczeg.github.io/sljit/pcre2_jit.html
The single character optimization described in the paragraph containing the
(*SKIP) verb should handle it.
Regards,
Zoltan
Eredeti levél
Hi Ze'ev,
you can follow the discussion here:
https://github.com/zherczeg/sljit/issues/89
The current aim of the project is Linux only, and no plans for mainframe
support.
Regards,
Zoltan
Eredeti levél
Feladó: Ze'ev Atlas via Pcre-dev < pcre-dev@exim.org (Link ->
Hi Petr,
yes, it is way too experimental to enable it in production.
Regards,
Zoltan
Eredeti levél
Feladó: Petr Pisar via Pcre-dev < pcre-dev@exim.org (Link ->
mailto:pcre-dev@exim.org) >
Dátum: 2020 november 9 13:42:03
Tárgy: Re: [pcre-dev] Release Candidate 10.36-RC1
Hi,
besides the input, could you upload a minimized single .c file where we can
reproduce what you are exaclty doing. I don't have mac, but a single file
program should work the same way.
Regards,
Zoltan
Eredeti levél
Feladó: Thomas Tempelmann via Pcre-dev <
Hi Ze'ev,
the only OS dependent part of JIT is the executable code allocator. Now the
compiler has 3 of them, one might work on your system.
Regards,
Zoltan
Eredeti levél
Feladó: Ze'ev Atlas via Pcre-dev < pcre-dev@exim.org (Link ->
mailto:pcre-dev@exim.org) >
Dátum: 2020
Hi,
PCRE2 has an optional executable allocator, which allocates temporary files on
the disk, where it stores machine executable code. The tmp directory can be
(optionally) set using the TMPDIR environment variable. The temporary file is
created by open(... O_TMPFILE ...) or mkostemp(). There
> Matching with jit, it was very easy to produce an example which
> exceeds the available resources: We take the pattern
> "(*LIMIT_MATCH=10)(x+x+x+x+)+y" and as subject we take a string of
> length 10 containing only the letter "x".
Philip summarizes this well. In case of your example, 5 x-s
> Could they be safely moved to the correct location please.
Hi,
those files are intended to be there. They are pcre-jit specific,
Regards,
Zoltan
--
## List details at https://lists.exim.org/mailman/listinfo/pcre-dev
Ok for me.
If anybody has time, please test the latest code.
Thank you,
Zoltan
Eredeti levél
Feladó: p...@hermes.cam.ac.uk (Link -> mailto:p...@hermes.cam.ac.uk)
Dátum: 2019 november 19 17:26:12
Tárgy: Re: [pcre-dev] Win32 JIT Access Violation
Címzett: Zoltán Herczeg <
hink it
is related. It feels like uninitialized memory access or buffer overrun.
I hope you can make use of this information. Feel free to ask fore more.
Many thanks,
Ralf
PS: Please release whenever you and Philip feel is the right time.
On 19.11.2019 08:48, Zoltán Herczeg wrote:
> I suspect someth
ev] Win32 JIT Access Violation
Címzett: pcre-dev@exim.org < pcre-dev@exim.org (Link ->
mailto:pcre-dev@exim.org) >
On 15.11.2019 09:01, Zoltán Herczeg wrote:
> thank you for the report. I don't have C++Builder, so I would need
> some help. The pattern is quite big, is it possibl
Hi Ralf,
thank you for the report. I don't have C++Builder, so I would need some help.
The pattern is quite big, is it possible to simplify it? Also bisecting the
change which broke it would be a great help as well.
Regards,
Zoltan
Eredeti levél
Feladó: Ralf Junker <
> > Please find attached the patch with recommended fixes from Petr.
> >
> Thanks. It fixes all the ARM JIT warnings.
Patch landed. Thank you for fixing all issues.
Regards,
Zoltan
--
## List details at https://lists.exim.org/mailman/listinfo/pcre-dev
tum: 2019 november 6 06:25:22
Tárgy: Re: [pcre-dev] JIT fails with NEON instructions
Címzett: Zoltán Herczeg < hzmes...@freemail.hu (Link ->
mailto:hzmes...@freemail.hu) >
Hi Zoltán,
please find attached a patch that fixes the problem.
For utf-16 and utf-32 the vectorization factor is a
with NEON instructions
Címzett: Zoltán Herczeg < hzmes...@freemail.hu (Link ->
mailto:hzmes...@freemail.hu) >
The problem occurs on Ubuntu 18.04 and A-72 as well
when configuring with --enable-pcre2-16 and --enable-pcre2-32
each exposes one fail.
I will send a patch to fix these i
Hi Sebastian,
could you check this failure?
Regards,
Zoltan
Eredeti levél
Feladó: Petr Pisar via Pcre-dev < pcre-dev@exim.org (Link ->
mailto:pcre-dev@exim.org) >
Dátum: 2019 október 30 18:25:42
Tárgy: Re: [pcre-dev] JIT fails with NEON instructions
Címzett: pcre-dev@exim.org
Hi,
> I was faced with a need of nonfixed length lookbehind two times:
> 1. when data came by stream of 24kB blocks and I need to find a last
>numeric in each of it
> /.{24000}(?<=(\d++)\D*+)/g
Even if this would work, the result of this would be always the last position
of the subject, and
Hi,
recently I have seen from Mac users that the JIT does not work on newer OS-es.
I just found the following link, where PCRE is explicitly mentioned:
https://developer.apple.com/documentation/bundleresources/entitlements/com_apple_security_cs_allow-jit
Does this help? If yes, it would be
> I think MOVE verb like a goto operator in programming languages impacts
> the clarity of pattern structure and make it error-prone. It is
> undesirable in my opinion.
Yes. The idea has already dropped.
> I think it will be better to use standard "(?<=)" for lookbehinds, not
The problem is
> > You are right. Since you can put it into a group, it is not possible
> > to prevent repetitions. However the rule that empty matches break
> > (non-fixed) loops may solve this problem.
> ... but it's not an empty match.
If we consider the following pattern:
/(*napla:a|a)+/
is the same as:
> as normal groups, not as assertion groups. What happens when they are
> repeated must be defined - or maybe they should not be allowed to
> repeat, because once again that might be an easy way to infinite loops.
You are right. Since you can put it into a group, it is not possible to prevent
> Let me see if I understand that: does (*match:{1}pattern) mean "apply
> the pattern to the string that is currently captured by group 1"?
> Without looking at the interpreter code, I'm not sure if this is easy or
> hard to implement.
This is just throwing some ideas. We could also decide that
this:
(submatch)(*match:{1}pattern) is easier.
Inside the {}, a name can be presented as well.
The (*MOVE) could be kept for moving the string pointer around.
Let me know your opinion.
Regards,
Zoltan
Eredeti levél
Feladó: Zoltán Herczeg < hzmes...@freemail.hu (Link ->
mailto
> > (*SETEND:mark_name)
> > - This verb changes the end position to the position recorded by the last
> > mark which name is
> mark_name. If the position is smaller than the current string position, it is
> set to the current string > position.
> By "end position" do you mean "end of subject"?
> May be it not quite effective and still have restrictions but is useful.
> Is it simple to add such functionality?
Definitely not easy in JIT.
I have an alternative solution which might be able to solve many of the issues
raised here. We already have (*SKIP:name), so we need to record
> I am still not entirely convinced this change should be made. Zoltán,
> what do you think? It would involve making changes to JIT, of course.
I don't really see where we are heading now, and the situation feels chaotic. I
wouldn't increase maintenace burden without strong reasons.
Regards,
> It turned out to be very easy to implement in the interpreter, but there
> was quite a lot of necessary but straightforward work to add new opcodes
> and process them in the various scans of compiled patterns. Also, the
> documentation took some time.
Somehow it doesn't feel right to call this
> /(?0)/
As far as I remember, these are detected by the parser.
Regards,
Zoltan
--
## List details at https://lists.exim.org/mailman/listinfo/pcre-dev
> A Perl developer has admitted there is some ambiguity, but suggests that
> (*COMMIT) just means "never advance the starting point". That pattern
> can find a match without advancing the starting point.
The documentation says two rules:
1) It's a zero-width pattern similar to (*SKIP) , except
> Note that if this operator is used and NOT inside of an alternation
> then it acts exactly like the "(*PRUNE)" operator.
> But it doesn't.
Perhaps the misunderstanding comes from the fact that we are talking about the
pattern and they talk about the matching process. So (*THEN) simply starts a
If you are right about the internal working of (*THEN), then this verb has a
very unclear and inconsistent behavior, which is very hard to track for a user.
I think it should made obsolete and removed eventually.
Regards,
Zoltan
--
## List details at
> Sorry but I can't build pcre2test for Windows with Visual Studio directly
> from svn. There are no simple "press and play" possibility to build. Docs
> about building by VS are miserly and obscure.
Some optimizations are not enabled on Windows compared to Linux which affects
your test case.
Hi,
> It seems JIT is 16 times!! slower than interpreter for such simple pattern.
I did some improvements on the SSE2 accelerated search and /(?s).*/ search. You
can try them now. However I have never seen such big differences in my
measurements. The memchr can use AVX2, so it is still faster,
> (?=x|y) looks much more ergonomical than (?:(?=x)|(?=y))
They behave the same way, so pick whatever you prefer.
Regards,
Zoltan
--
## List details at https://lists.exim.org/mailman/listinfo/pcre-dev
> But why assertions are atomic? I guess answer is: "Because it does in
> Perl". But why?
Assertions are like "if" statements in structured languages. A condition part
of an "if" is never retried.
Regards,
Zoltan
--
## List details at https://lists.exim.org/mailman/listinfo/pcre-dev
> We found that PCRE internally uses GNUWin32.
Where?
Regards,
Zoltan
--
## List details at https://lists.exim.org/mailman/listinfo/pcre-dev
Hi,
that is strategical difference. You don't know the input from the pattern, and
your input has no a-d characters. The interpreter only searches 'a', while jit
searches two characters: 'a' and 'd' which distance is two. The latter is more
complicated, but works better for random input. You
ink -> mailto:airw...@gmail.com) >
Dátum: 2019 március 5 10:55:27
Tárgy: Re: [pcre-dev] PCRE2 10.33-RC1 available for testing
Címzett: Zoltán Herczeg < hzmes...@freemail.hu (Link ->
mailto:hzmes...@freemail.hu) >
Hi Zoli,
thanks for clarification,
On Tue, Mar 05, 2019 at 10:44:36AM +0100, Zo
Hi Ervin,
sparc64 has not supported yet, and I have no plans to do it in the foreseeable
future. However, if somebody is interested to do it, just submit a patch to the
JIT compiler:
https://github.com/zherczeg/sljit
I will migrate the code to pcre/pcre2 after it is landed.
If somebody knows
Hi,
there have been many requests on this list which were regular expression
related but not exactly pcre related. We have been worked on some of them, e.g.
glob matching, but we usually haven't fully finished them and honestly never
felt like they should be part of pcre. I always suggested
Hi Ervin,
The result value is misinterpreted by showresult (). PCRE_ERROR_NOMATCH is -1,
not 0. The 0 value represents that a match is found, but the ovector is too
small to store all capturing bracket positions. So increasing #define OVCOUNT
from 30 to 40 "solves" the JIT case. For some
Hi,
my opinion is that this is kind of beyond the scope of pcre. For some time
(years actually, but I had no time to start it) I have been thinking that the
world would need a regex optimizer framework. It could do a lot of things
except pattern matching. It would build an AST from the
Dear PCRE2 users,
since PCRE 10.32 has been released, it is time for announcing a new major
feature for PCRE2-JIT: supporting invalid UTF subject strings. This feature can
be enabled by passing PCRE2_JIT_INVALID_UTF option to pcre2_jit_compile(). It
is recommended to use pcre2_jit_match()
> I can understand that. But I would point out that PCRE2's current notion
> of serialization is quite limited compared to what that word usually
> implies (cf. Java, .NET object serialization), so this is not likely to
> be the only time that an application developer finds the functionality
>
Hi,
> In my use case, however, the application has binary data files
> [containing serialized regexes] under /usr/share/foo/, and no provision
> is available to cache under /var/, nor any other writable disk location.
> PCRE2 can be updated at any time due to security vulnerabilities, but
> the
Hi,
to tell the truth, when the serialization was created the use case we were
discussing was different from the use case below.
I consider serialized forms inherently unsecure. I would never recommend to
accept any regexes in binary forms for any application. Instead, I would
recommend to
Hi,
there are many problems with invalid utf8 strings. Here is some thoughts from
previous discussions:
- What is type of an invalid character. Is 0xe9 a latin é letter, or something
else?
- What is a lowercase/uppercase pair of an invalid character.
- Moving around: if you start a match from
Hi,
do you use JIT?
The engine has special single character optimizations to make /.*/ fast. The
generic /(?:anything)*/ is much slower.
The numbers below are reasonable. E.g. using capturing bracket is the slowest:
/(.)*/, since you need to store extra data.
Yes, you can make pattern
Hi,
for some time I have been thinking about creating a regex optimizer which does
everything except matching. It could analyze and optimize patterns.
Unfortunately I don't have time working on it., so it is unlikely it will be
available in the foreseeable future :(
Regards,
Zoltan
Hi,
> This was a patch to Git as you might have guessed:
> https://public-inbox.org/git/20171122133630.18931-2-ava...@gmail.com/T/#u
> Do you think I need to go back and rework that so I do #1 as well? A
> pedantic reading of the manpage would probably suggest so, but I can't
> see how the JIT
Hi,
hm, interesting problem. I don't remember how this should work. Anyway, I
checked the code:
pcre2_jit_compile:
if ((re->flags & PCRE2_NOJIT) != 0) return 0;
So it returns with success if NOJIT is present. That is perhaps misleading. I
wouldn't mind changing this.
pcre2_jit_match:
if
Hi,
this is great news! Thank you very much for the hard work on the integration!
Regards,
Zoltan
Eredeti levél
Feladó: Ævar Arnfjörð Bjarmason via Pcre-dev < pcre-dev@exim.org (Link ->
mailto:pcre-dev@exim.org) >
Dátum: 2017 augusztus 9 01:47:52
Tárgy: [pcre-dev] Git 2.14.0
Hi,
I fixed the PPC warning. Thank you for the report. I will not be available this
week, and can fix other issues next week.
Regars,
Zoltan
--
## List details at https://lists.exim.org/mailman/listinfo/pcre-dev
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
Thatll only work if pcre isnt compiled with --disable-jit, if it
is
even on the latest svn trunk linking
Hi,
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
Regards,
Zoltan
Eredeti levél
Feladó: Ævar Arnfjörð Bjarmason avarabgmail.com (Link -
>>>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 search optimization in JIT. It is still in progress
(corner cases), although you can
Hi,
>JIT is enabled in Debian on pcre builds for some architectures (roughly,
>those where it's believed to work ;-) ). It was true in old-pcre (Debian
>calls this pcre3) at the point I took over looking after pcre for
>Debian, and so I made it so for pcre2 also.
This is great news indeed! The
Hi,
>I couldn't find out how to get the compile flags for those, but
>presumably it's some comparable middle-of-the-road value, probably
>-O2. I'll try compiling from svn & report back.
Likely -O2. I am surprised that JIT is enabled in default builds. I am sure it
wasn't in the past.
>> This
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 10% slower
>than v1 when both use JIT.
I would like to see the compilation flags for
In case of anchored matches, there is no need to scan the input for possible
starting characters. Several other simplifications (optimizations) are possible
as well. So the generated code is different.
You can compile the pattern twice though and use the appropriate one.
Regards,
Zoltan
...@gmail.com> írta:
>Hello,
>
>On Tue, Dec 20, 2016 at 4:03 PM, Zoltán Herczeg <hzmes...@freemail.hu> wrote:
>> Personally I wouldn't mind transferring the ownership of the project, so if
>> you wish to be the owner, I can give the it to you. And you can decide how
&
>Forgot to reply to this part -- would you prefer to keep using the
>existing "pcre" project, and upload PCRE2 builds there (given PCRE1 is
>reaching EOL anyhow), or keep using "pcre" for PCRE1 and request a new
>project for PCRE2?
Personally I wouldn't mind transferring the ownership of the
Hi,
I tried this tool a long time ago, and uploaded pcre perhaps twice, but I
wasn't satisfied with its output since it hasn't reported any relevant issue.
It produced a huge report though, and took a lot of time to check everything.
>*** CID 11125: Null pointer dereferences (FORWARD_NULL)
,
Zoltan
Christoph Biedl <debian.a...@manchmal.in-ulm.de> írta:
>Zoltán Herczeg wrote...
>
>> Another idea just came to my mind. This issue could be cache flush issue,
>> since the CPU executes instructions from the instruction cache, while gdb
>> prints instructions
/20160406.071510.a067ef1f.en.html
Might be the cause of the issue.
Regards,
Zoltan
"Zoltán Herczeg" <hzmes...@freemail.hu> írta:
>Hi Christoph,
>
>>Very likely not. I saw SIGILL from other code, gdb pointed right to
>>the place. So, just as another example:
&g
Hi Christoph,
>Very likely not. I saw SIGILL from other code, gdb pointed right to
>the place. So, just as another example:
Just asking :) Yes, SIGILL should be precise on all cpus.
>| (gdb) disassemble 0xb7fe40a8,0xb7fe40c8
>| Dump of assembler code from 0xb7fe40a8 to 0xb7fe40c8:
>|
Hi Philip,
great news! This really a great step ahead. Thank you for the hard work! I will
do some JIT testing in the coming weeks.
Regards,
Zoltan
p...@hermes.cam.ac.uk írta:
>To PCRE2 users:
>
>Over the last few months I have been refactoring the way pcre2_compile()
>works. The new code,
Hi,
this mailing list is about pcre library development, not general regular
expression questions. Reddit is the right place for those tricky questions:
https://www.reddit.com/r/regex/
I try to answer your question though. Since the number of "string" tags are
unknown, I would convert this in
Hi,
svn co svn://vcs.exim.org/pcre/code/trunk
svn co svn://vcs.exim.org/pcre2/code/trunk
Regards,
Zoltan
Lokesh Ubuntu írta:
>Hi,
>
>Am looking for pcre latest(later than 8.38) source, if possible could you
>pls help on? It would be really appreciated!!
>
>Thanks in
Hi,
thank you. I was curious whether System Z has a power CPU, but it looks like it
is an exotic system.
Regards,
Zoltan
"Ze'ev Atlas" írta:
>ZoltanFew years back, when I was working on porting PCRE to z/OS , you thought
>about developing JIT for that stuff. Both Philip
>Does it mean that (*SKIP:label) looks for the (*MARK:label) in the regex
>execution stack to figure out where to bump along to?
Exactly. It searches the last MARK in the regex stack which name matches and
restart the match from there.
E.g.: when /x(*:a)x(*:a)(*SKIP:a)(*FAIL)|./ matches to
Hi Thanh,
I think these questions are better suited to https://www.reddit.com/r/regex
anyway, I think the /g causes the regex to match all characters. Without that
it probably just matches only one character, as you can see in regex101. The
first half of your second assumption is correct, the
>The biggest problem is having this working (and claim as supported)
>amongst the huge number of compilers and platforms that PCRE2 runs on.
>That's not an easy task.
this is exactly my problem :)
Perhaps we could start by supporting some platforms, and gradually cover more
with the community
>Do you mean that PCRE internally will read/save the JIT-compiled data
>inside the pcre2_code using atomic operations?
Exactly. The JIT compiler produces a pointer, and storing that pointer is an
atomic operation. When that pointer is stored, it becomes "active". If
compilation fails, the
Hi,
the JIT compilation itself should be thread safe as before (no global variables
are used for compilation). You can compile multiple patterns on multiple
threads in the same time, and you can even use a pattern while JIT compilation
is in progress on another thread. In theory at least, let
>lock(mutex);
>extra = pcre_study(code, ...);
>unlock(mutex);
>/* then proceed to match as usual */
you can do this now as well. Just replace pcre_study to pcre2_jit_compile.
There is no need to check JIT availability, the call will return with an error
in that case (and you can silently ignore
) of those changes. It
would be better to discuss proposed patches and land the best solution.
Regards,
Zoltan
"Giuseppe D'Angelo" <dange...@gmail.com> írta:
>On Mon, Jan 4, 2016 at 8:58 PM, Zoltán Herczeg <hzmes...@freemail.hu> wrote:
>> Probably a write barrier wo
Hi,
it seems SSE2 caused problems there. The log does not reveal too much about the
problem other than some segmentation fault.
Regards,
Zoltan
Dagobert Michelsen írta:
>Hi,
>
>I noticed that JIT is failing for some time now on Solaris 10 x86 for
>both x86 and amd64:
>
>
Hi,
I am sorry I forgot to reply. Philip guess was right, JIT can only use 64K
machine stack, and it cannot compile the pattern if it runs out of it. The
exact rules are not documented since they may change any time when new
optimizations are introduced (e.g. a capturing bracket may use 2 or 3
>It's very bad news for me.
>Yesterday I test my patterns (each have around 1,5-2M size) and find that
>JIT don't work with all of they.
>Unfortunately this patterns can't be splitted due to it's automatically
>construction.
>Is there way to grow this 64K stack size or another way to use JIT?
May have a question about pcre executable portability? Not all x86 machines
support SSE2. Is it there a run-time check for SSE2 support with a fall-back
code, or is it a compile time option?
The SSE2 code path is optional. It is checked at runtime using CPUID
instruction on x86-32 (it is always
May have a question about pcre executable portability? Not all x86 machines
support SSE2. Is it there a run-time check for SSE2 support with a fall-back
code, or is it a compile time option?
The SSE2 code path is optional. It is checked at runtime using CPUID
instruction on x86-32 (it is always
Hi,
this is just a notification that I recently added x86 SSE2 support to
PCRE2-JIT. This improves the performance of first character search. The code
is mostly ready, but testing may reveal some issues. I also expect some false
positive valgrind reports, since the code performs 16 byte
don't know how to code that in pcre.
Fred
On Sat, 6 Jun 2015 18:33:28 +0200 (CEST), Zoltán Herczeg
hzmes...@freemail.hu wrote:
Hi Frederic,
I just realized that results on that page are two years old. So I updated
the engines to their most recent versions and uploaded new results
Hi Christoph,
I'm having a single threaded application. How could it happen that
patterns are not matched sequentially? AIUI, nested calls to
pcre_exec() or pcre_jit_exec() would have to be made, which could only
happen if this is done from a callback, such as the pcre_jit_callback
passed to
Hi Jacob,
Philip Hazel decides when the next PCRE release will come out. He seems very
busy now, perhaps with real life things. You know this project is completely
volunteer development which has advantages and disadvantages. He may prefer to
fix the remaining known issues first.
Anyway, you
from the last pattern was
decreased to 27 ms from 190 ms.
Regards,
Zoltan
Zoltán Herczeg hzmes...@freemail.hu írta:
Hi Frederic,
thank you for measuring PCRE on PPC. The results are quite interesting.
It seems to me that those patterns are slower whose require heavy
backtracking. I mean where
Hi Frederic,
thank you for measuring PCRE on PPC. The results are quite interesting.
It seems to me that those patterns are slower whose require heavy backtracking.
I mean where fast-forward (skipping) algorithms cannot be used (or they match
too frequently). The /[a-zA-Z]+ing/ is a good
Hi Frederic,
the sljit compiler uses SSE2 only for floating point computation, and not for
SIMD computation. PCRE-JIT only uses integer computation, so it does not even
use the SSE2 part.
We had discussions about using SIMD for regex matching, but nothing was
implemented so far. The
Hi,
you need to use capturing brackets or MARK control verbs to get info about the
match. I think MARK is more convenient, since you don't need to iterate over
the ovector. Instead you can simply read the mark pointer in the extra data.
Regards,
Zoltan
t t russ_9...@hotmail.com írta:
Hello,
Thank you for the help. The fix is landed in r1551.
Regards,
Zoltan
Petr Pisar ppi...@redhat.com írta:
On Thu, Apr 23, 2015 at 11:51:36AM +0200, Zoltán Herczeg wrote:
I think the following instruction is the problem:
0x03ffb7cc0010: stp x29, x30, [sp,#-56]!
sp must be 16 byte
I think the following instruction is the problem:
0x03ffb7cc0010: stp x29, x30, [sp,#-56]!
sp must be 16 byte aligned all the time.
Petr, I will send you a patch. Let me know if it fixes the problem.
Regards,
Zoltan
--
## List details at
instruction might help for me
to understand the issue.
Regards,
Zoltan
Petr Pisar ppi...@redhat.com írta:
On Thu, Feb 26, 2015 at 07:13:39PM +0100, Zoltán Herczeg wrote:
I don't think these are related. The problem is in test2, not in test19 (the
serialization test). Sparc64 JIT has not implemented
Hi,
yes, pcre_int32 and pcre_uint32 are always 32 bit long. However, there are
other types: int_fast32_t / int_least32_t which might be more than 32 bit long
and provides faster 32 bit computation. PCRE does not use them (at the moment).
See here:
1 - 100 of 228 matches
Mail list logo