:
On Thu, 26 Feb 2015, Giuseppe D'Angelo wrote:
On 26 February 2015 at 12:39, Zoltán Herczeg hzmes...@freemail.hu wrote:
The message bus error is also interesting, not the usual segmentation
fault. I don't know this error, but according to wikipedia, a bus error
is a fault raised by hardware
Hi Petr,
thank you for running PCRE2 on many environments.
The AArch64 is worse. It compiles with JIT but crashes on tests:
FAIL: RunTest
=
PCRE2 C library tests using test data from ./testdata
PCRE2 version 10.10-RC1 2015-02-20
Testing 8-bit library
Test 0: Unchecked
Hi,
src/sljit/sljitNativeARM_32.c:340:28: error: 'compiler' undeclared (first use
in this function)
SLJIT_FREE(curr_patch, compiler-allocator_data);
^
src/pcre2_jit_compile.c:60:61: note: in definition of macro 'SLJIT_FREE'
#define SLJIT_FREE(ptr,
The (?:abc){1234} is a simple case, but sometimes you need to track the status
of the subpattern. E.g. when you match /(?:aa|a){6}/ to aa (this is a badly
written, but possible pattern requires exponential matching time). The engine
greedily matches aa at the beginning, but eventually it
Hi,
the pattern is always compiled to byte code first, and JIT converts it back, so
using JIT alone does not help. The reason of not using an iterator in the
interpreter is practical: PCRE interpreter uses stack recursion, and you cannot
easily share variable data across function calls. This
Hi,
I wanted to say something similar. Now PCRE cannot be built without UCP if UTF
is enabled, but using it is a different question. You can modify the behavior
of \w etc. in the same was as in PCRE1.
Regards,
Zoltan
Giuseppe D'Angelo dange...@gmail.com írta:
On 5 January 2015 at 17:57,
Hi,
this was simply an oversight from my side (after some refactoring). The
mcontext can be NULL. Thank you for noticing it. I hope I fixed it.
Regards,
Zoltan
Ralf Junker ralfjun...@gmx.de írta:
PCRE2 pcre2jit.html:
The fast path function is called pcre2_jit_match(), and it takes
exactly
Hi,
That's an error in the docs, incorrect editing of the PCRE1 document.
What it should be saying is that you can use PCRE2_INFO_JITSIZE. If the
result is non-zero, JIT compilation was successful. Thanks for noticing!
This gives a bit more depth to JIT complation check. In PCRE2, you can call
Hi,
It has almost as many matching features as PCRE with same syntax, and is
guaranteed non-backtracking with linear time performance in the length of the
input.
Hm, not exactly. Re2 never said that. They have a list of available features,
and the more interesting ones are all grayed out:
Hi Ralf,
Thank you for the feedback. I hope I fixed it (r1512). Let me know if there are
more issues.
Regards,
Zoltan
Ralf Junker ralfjun...@gmx.de írta:
Since SVN #1507, JIT no longer compiles for _WIN32.
In particular, sljitUtils.c, lines 242 and 249 are missing the new
allocator argument.
Hi All,
let me start with some good news: the JIT compiler is ported to PCRE2, and
mostly working (or better to say it has not extensively tested yet).
But the main topic of my mail is starting a discussion about the default
configuration in PCRE2. In PCRE1, we had a rather simple approach:
Hi Laurent,
thank you very much for spending time on fixing bugs in PCRE! I really
appreciate it.
I also found these issues and fixed them yesterday:
https://tahini.csx.cam.ac.uk/lurker/message/20140326.182344.f2586b5b.en.html
Me neither have hardware, but these changes are clearly needed. The
Hi Petr,
thank you very much for the testing! This is really a great help for us.
Could you try the MIPS-64 port as well?
You are the first one who actually has an ARM-64 hardware :) The developer
branch of qemu A64 does not support all instructions, so it fails when
SLJIT_CACHE_FLUSH is
Hi,
If you don’t mind I will just leave all 8 builds activated, personally I would
consider sparc64-jit the most relevant build besides amd64-jit for Solaris so
make it a +1 from me to encourage you to add the remaining part :-)
I will try to add it, but likely not in the near future.
Hi,
One more issue is that I did not clean up the build directory between
builds, it was essentially an svn update followed by configure, make,
make check. Now that I do a full clean inbetween everything passes.
Maybe a dependency is missing in the Makefile, but I can happily live
with rebuilding
Hi,
Undefinedfirst referenced
symbol in file
pcre_jit_exec pcre_jit_test-pcre_jit_test.o
pcre16_jit_exec pcre_jit_test-pcre_jit_test.o
pcre32_jit_exec pcre_jit_test-pcre_jit_test.o
Hi,
How about making another list for such automatic messages? They
clutter a bit this list (which is supposed to be for discussing
development).
I agree that this list is mostly for porting questions, reporting bugs and
requesting features.
PCRE has only a few developers. When somebody does a
Hi,
this mail is a summary of another performance optimization which was recently
added to the JIT compiler. The new code is basically a simplified version of
the Boyer–Moore string search algorithm, and its purpose is searching for fixed
prefixes.
The first step is finding the longest fixed
Hi,
In Linux, it just prints the rest of the string, starting at the start
position - I think this is probably accidental. When the length of the
matched string is negative, it prints to the end of the string.
Presumably in your case there isn't a trailing zero...
I didn't know it is
Hi,
Can you explain, why capturing atomic groups with capturing brackets
inside can't produce tail recursion in cases when '(?:' can do this?
because PCRE has to prepare for the worst case scenario. Your input string does
not match to the capturing bracket, so the capturing bracket does not
Hi,
Anyway I suspect the result is correct (it start with b)
I don't think so. Result must not have 'b'.
Did you see my other mail yesterday? I explained there that pcretest yields 'b'
for testing purposes (it handles startoffset is greater than endoffset cases
this way). I also described
) is bigger than end offset (0), print input to the end b
Hope this helps,
Zoltan
Zoltán Herczeg hzmes...@freemail.hu írta:
Hi,
yes it seems there is a rubbish after the 'b'. However, I don't see this
behavior in the recent release (under Linux at least), and your binary is half
year old. Could you
Hi,
yes it seems there is a rubbish after the 'b'. However, I don't see this
behavior in the recent release (under Linux at least), and your binary is half
year old. Could you try it with a newer version?
Anyway I suspect the result is correct (it start with b), just the printing
does not
Hi Naden,
I like that you always have some interesting questions :) It is great to talk
about the internals and optimizations of PCRE.
Here is the answer to your question: in the second case, you see the effect of
an optimization called tail recursion. You can even see that in the first
case,
Hi,
no. This is an experimental new feature. The patch is not even in trunk.
Anyway, I don't think it will affect your port, since it is UTF only.
Regards,
Zoltan
Ze'ev Atlas zatl...@yahoo.com írta:
Is the patch already incorporated in the latest version of 8.34?
I'd like to download the best
Hi
This doesn't answer the question whether the
pre-compilation would fail on JIT-enabled systems,
or perhaps it would still speed something up?
I am not sure I understand this question, but you can pre-compile a regex, save
its byte code, reload it, and compile with JIT. You cannot save and
Hi Petr,
thank you for the report, and sorry for the late answer.
The bug is fixed here:
http://lists.pcre.org/lurker/message/20131130.070502.fb1cef50.en.html
Regards,
Zoltan
Petr Pisar ppi...@redhat.com írta:
On Tue, Nov 19, 2013 at 03:47:09PM +, p...@hermes.cam.ac.uk wrote:
I have just
), but if this is
important for many people, we might think about this later.
Regards,
Zoltan
p...@hermes.cam.ac.uk írta:
On Sat, 23 Nov 2013, Zoltán Herczeg wrote:
PCRE supports 2 or 4 byte character encodings, but character
properties are only supported for 0-255 character codes.
I think I had
Hi Rand,
thank you for the report, and sorry for the late answer. We did a lot of rework
on auto-possessifying in PCRE, and the code still requires testing. I suspect
--enable-unicode-properties was not passed to configure since I only see this
error when it is not there. The fix was trivial,
Hi all,
we have been working on the auto-possessifying optimization in PCRE for some
time, and I would like to give you a brief summary of the results we achived.
This optimization replaces greedy/non-greedy single character repetitions with
their appropriate posessive form. A simple example
Hi Yaron,
I started to sketch up something about the advantages and disadvantages of
different engine types:
http://sljit.sourceforge.net/regex_compare.html
I plan to add more info in the future.
Regards,
Zoltan
Zoltán Herczeg hzmes...@freemail.hu írta:
Hi Yaron,
It depends on your patterns
Hi,
How would you make a pattern to extract lines that violate the format?
This should be really easy using negative assertions. E.g: a line must match
/^PATTERN$/ (non-multiline match). A non-matching line can be listed as:
/^(?!PATTERN$).*/
Regards,
Zoltan
--
## List details at
Hi,
JIT is typically used by server applications such as NGNIX webserver, Suricata
Intrusion Detection System, ModSecurity firewall, etc. and it seems they are
happy with it. Some Korean guys made a paper about integrating JIT into Snort:
http://kiise.or.kr/e_journal/2013/4/CST/pdf/01.pdf They
Hi,
I think one of the drivers for a new API is that the current (int)
option bits are pretty much all used up. I don't know how the new API
might address that. I'm saying that OPCRE would still define its
options as (int) while the equivalent set of options in NPCRE might
not fit in a
, 1) as well? If the offset is really
incorrect, probably common-start-re will not be equal to 56.
Regards,
Zoltan
Ralf Junker ralfjun...@gmx.de írta:
On 13.05.2013 12:36, Zoltán Herczeg wrote:
this is quite interesting. Am I see right, that your pattern only contains
two fixed characters
, 1) as well? If the offset is really
incorrect, probably common-start-re will not be equal to 56.
Regards,
Zoltan
Ralf Junker ralfjun...@gmx.de írta:
On 13.05.2013 12:36, Zoltán Herczeg wrote:
this is quite interesting. Am I see right, that your pattern only contains
two fixed characters
, 1) as well? If the offset is really
incorrect, probably common-start-re will not be equal to 56.
Regards,
Zoltan
Ralf Junker ralfjun...@gmx.de írta:
On 13.05.2013 12:36, Zoltán Herczeg wrote:
this is quite interesting. Am I see right, that your pattern only contains
two fixed characters
Hi,
dot (.) is the inverse of \R.
If you need to match everything, use [\x00-\xff] or (.|\R) or \p{Any} (the
latter only if unicode is enabled). I would choose the first for ascii, and the
third for unicode matches.
Regards,
Zoltan
pcun...@fsmail.net írta:
I have read the entire PCRE
Hi,
We could create a PCRE project on github, thus allowing some other
people to take management of the whole thing - in this case we could
move the wiki across very easily and change tahini's redirects. It
would also be possible to reflect the svn repository into a github git
repository
Hi Ralf,
Many thanks! I will keep an eye on SVN development and will be available
for testing!
Philip told me, that I can simply reconstruct repetitions in JIT, instead of
introducing new opcodes and do other changes in the interpreter. The
reconstruction is imprecise, e.g
Thanks... I'm so sorry but my bad English don't allow me understand this.
Is there other word's? I don't feel how to speed up my application by
using another thread.
You probably have a list of patterns (array, linked list, etc.). Each item
should have a pcre and a study. When your
This is an exponential case for the code generator. It is similar to the one
which is sent by Ralf recently.
In PCRE, if P is not a character literal or a backreference, (P){n,m} is
expanded to
(P)(P)(P)...(P)(?:(P)(?:(P))?)?
The code generator optimize these patterns one-by-one, and
Hi,
definitely worth investigating it. However, I cannot see it on my 64 bit Linux
machine. I have some questions:
- these patterns simply match to ab, because of the non-greedy quantifier.
That requires a very small amount of memory. Is this intentional? What is your
input for these
Hi
My compiler and environment are very different from yours. In particular
I do not have alloca(). I replaced the only call to alloca() by char
array[SLJIT_MAX_LOCAL_SIZE]; according to your recommendation a long
time ago.
But this also affects runtime only, not compile time. I am afraid it
Hi All,
all backtracking verbs are supported by the JIT compiler. It was a considerable
amount of work, and many things were changed, so please test the engine. We
also had discussions with Perl devs, which resulted some changes: there is no
priority order between backtracking verbs anymore,
Hi,
Zoltan, have you time and possibilities to make support of backtracking verbs
in JIT?
It's will be another great deal!
I don't have much free time nowadays. Which one is the most important for you?
I was thinking about them and they are difficult (not surprisingly they are the
last
Hi,
JIT support is added.
Regards,
Zoltan
p...@hermes.cam.ac.uk írta:
I have committed a patch that puts the bumpalong offset into the third
element of the offsets vector when the interpreter is used. This applies
to both hard and soft partial matching. pcretest has been modified to
show this
Just to make sure I understand what you are suggesting: instead of
returning the earliest character that was inspected, you want it to
return the starting point of the last match attempt. Is that right? I
presume you then expect to use that offset minus the max lookbehind to
discover what
Hi all,
I would like to announce that callouts are working in JIT now, and all patches
were landed! The only thing which is not supported is callouts between a
conditional block and its condition. At the moment this can only be inserted
using auto-callouts, which is probably not the best use
you recommend me start
point? As well as if I'll have patch for review can I send it here?
-Original Message-
From: Zoltán Herczeg [mailto:hzmes...@freemail.hu]
Sent: Tuesday, February 12, 2013 1:47 PM
To: Roman Vasilyev
Cc: pcre-dev@exim.org
Subject: RE: [pcre-dev] PCRE GPU offload
Now
Hi,
JIT is designed to fall back to interpreted execution if a pattern is not
supported. So you can enable it even if not all patterns will be supported by
it. I hope the majority of your patterns are already covered by now.
Regards,
Zoltan
ND nad...@mail.ru írta:
On 2013-02-13 18:44, Zoltán
Sorry, understood.
So main idea, that OpenCl not fits PCRE let's call it string stream?
Yes. If your input is let's say 1 Mbyte, and you search /abc/, and it is found
in the first 100 bytes, running the same kernel on the remaining 1 million -
100 starting positions is a waste of time. I am
Now I'm completely clear where is the problem.
But seems like OpenCL doing it same way as OpenSSL makes AES en/decryption.
It uses 16byte blocks for operation, just you know you using full 16 or just
part of it.
And in case of texture size, you can create smaller texture size and upload
Hi Naden,
ok, I will work on this feature. It is not an easy task, so I cannot promise
when it will be done.
Regards,
Zoltan
ND nad...@mail.ru írta:
Hi, Zoltan!
The question is what to do. 1. Is it worth to implement a restricted callout
mechanism (some members are set to an invalid
Hi,
no. And it shouldn't. The effectiveness of caching depends on the use case, we
should let the applications decide by themselves.
Regardless, caching is good. We wrote a short research paper about it a long
time ago: http://www.inf.u-szeged.hu/~akiss/pub/pdf/hodovan_regex.pdf
Regards,
...@gmail.com írta:
Hi,
On 26 January 2013 23:18, Zoltán Herczeg hzmes...@freemail.hu wrote:
Hi,
This is a heads up of a two recently landed fixes for those, who maintain a
binary pcre library. These are critical fixes, but easy to backport:
Patch: https://lists.exim.org/lurker/message
Hi,
This is a heads up of a two recently landed fixes for those, who maintain a
binary pcre library. These are critical fixes, but easy to backport:
Patch: https://lists.exim.org/lurker/message/20130126.175148.60d4ca3c.en.html
Effect: input string might be read after the end. Maximum of 4
Hi,
I know this issue. PCRE_STATIC was defined when you built the library, but not
when you used it.
Regards,
Zoltan
Алексей Павлов alex...@gmail.com írta:
Hi everybody!
I have builded pcre-8.32 as static with mingw-w64. When I building Qt with
system-pcre I got errors:
Hi Giuseppe,
I am interested in Philip's opinion, but in general I think PCRE should always
be fully thread safe.
Regards,
Zoltan
Giuseppe D'Angelo dange...@gmail.com írta:
I know it is already :-) By looking at its source code, it just
extracts information from the compiled pattern and the
Thanks Naden for finding this sophisticated bug. Fix is landed.
I was thinking about security as well, whether this bug can be exploited in any
way. Fortunately it is not possible to do a buffer overflow or any other crash,
only some patterns do not mach when they should.
Regards,
Zoltan
ND
Hi,
thanks for the report! After some investigation I realized that link_size=3 is
required for this bug to appear. And it was a typo in
fast_forward_first_n_chars(...):
-pcre_uchar *cc = common-start + 1 + IMM2_SIZE;
+pcre_uchar *cc = common-start + 1 + LINK_SIZE;
Philip, do we have tests
Each user gets its own writable data section; read-only data sections
are instead shared between the users.
I don''t think anything would work without a private .data and .bss section. As
far as I remember the point of static libraries is that they use position
independent code, so they can
Hi Arpe,
thanks for your suggestion! Just my two cents: the reason of the search is that
it shouldn't be a bottleneck. I suspect it takes less than 1% of the total
compilation time, although I never really measured it. I think before we jump
to coding, we should measure it somehow.
I wouldn't
Hi
am I understand correctly that no JIT is involved here?
You tell me :-) I certainly built PCRE with JIT support...
pcretest runs tests without JIT by default. -s+ needs to be passed to pcretest,
or s+ to a specific test to enable JIT. The bad pattern has s flag, bot no plus
so it is
this particular test (line 1426 and 1427 from
testinput2).
Regards,
Zoltan
Daniel Richard G. o...@teragram.com írta:
On Sun, 9 Dec 2012, Zoltán Herczeg wrote:
Daniel, please test the current code, and let me know if any other
issues remain.
Alas, still getting some test failures from r1235 on 64-bit
No strong opinion. I think the use case matters. Your example is a simple
implementation of posix regex. PCRE is much more complex, but if you don't need
its features, this simple code can do as well. PCRE searches the first
occurrence of a pattern, and returns a lot of info like the position
Thank you, Philip.
Daniel, please test the current code, and let me know if any other issues
remain.
Regards,
Zoltan
Philip Hazel p...@hermes.cam.ac.uk írta:
On Thu, 6 Dec 2012, Daniel Richard G. wrote:
On Thu, 6 Dec 2012, Graycode wrote:
Yet the CMakeLists.txt file currently contains:
Hi,
I landed a somewhat bigger patch, which contains all changes you reported in
the last few weeks. Thanks for porting and testing! I saw there are some
conversion related warnings as well, let me know if you have any fixes for them.
Regards,
Zoltan
--
## List details at
Hi,
I don't think so. In WebKit we did some OpenCL optimizations, but I am not sure
the general concept of a backtracking, NFA based engine is suitable for OpenCL.
At least the whole engine is surely way too big. Perhaps something like the JIT
compiler could work, just generating C like code
And the JIT compiler is improved a lot (based on the data revealed by
profiling). Many patterns run 20-40% faster.
Regards,
Zoltan
Philip Hazel p...@hermes.cam.ac.uk írta:
I have just put the 8.32 release onto the FTP site:
It would be easy enough to test---just disable the cpp case that uses
__cpuid().
I cannot. GCC supports ATT sytax only. Visual C does not support any inline
assembly in 64 bit mode: http://msdn.microsoft.com/en-us/library/wbk4z78b.aspx
(And I can confirm that is true). However, we might be
Hi,
Well, our audience here isn't just people following the list today, but
also people Googling for this information years from now. Hello readers in
2017! :-)
still feels out of scope. SourceForge provides some kind of forum, perhaps we
could use that:
Hi Daniel,
Only problem is, it's not clear how the assembly should refer to local
variables (from and to). I was reviewing this article...
I may misunderstand something here, but I thought you target sparc not x86.
Why not provide an Intel-syntax equivalent of the ATT assembly instead of
an
Hi Petr,
thanks for the measurements.
All warnings are caused by a single macro on PPC64:
#define SLJIT_FUNC_OFFSET(func_name) ((sljit_sw)*(void**)func_name)
Does anyone know how to fix this?
Regards,
Zoltan
--
## List details at https://lists.exim.org/mailman/listinfo/pcre-dev
Hi Daniel,
thanks for the patch! Would it be a problem, if I would land it after the next
pcre release? We focus on fixes now, and this is kind of a new feature.
* Added defined(__INTEL_COMPILER) to the appropriate conditionals
* Moved the 64-bit _MSC_VER case up so that this is used in
Hi,
thanks for the fixes. They are all landed now (although in multiple fragments).
And thanks for porting sljit to a large number of exotic systems.
Regards,
Zoltan
Daniel Richard G. o...@teragram.com írta:
Building PCRE with JIT support on a Solaris x86-64 system with the vendor
compiler
Hi,
I am still a little lost of this masking feature. I know why we need it in
compile. But why we need it in exec? I know if you read a character, which is
0x10, and read its UCD value (e.g matching to a unicode property), you get
a crash regardless of masking. But that is ok, since the
-Running in 16-bit mode but pattern was compiled in 32-bit mode
+Running in 16-bit mode but pattern was compiled in 0-bit mode
I fixed this issue.
Regards,
Zoltan
--
## List details at https://lists.exim.org/mailman/listinfo/pcre-dev
Hi,
I just landed a major JIT compiler update in PCRE. The new code mostly contains
code refactoring and bugfixing in MIPS and PowerPC ports. An experimental Sparc
32 support is also added.
I noticed that all big endian systems complain that:
-Running in 16-bit mode but pattern was compiled
Hi,
I am not sure I totally understand your mail. You have a string, which length
is 1G, and you want to display the first 1000 characters, and replace literals
(characters?) with another symbol, is that correct? Why do you need pcre for
this purpose? A simple loop which checks every character
I have cmake + windows box, so I will check this patch in due course.
Regards,
Zoltan
Daniel Richard G. o...@teragram.com írta:
I was building PCRE on Windows, but the pcre_test_bat test was not working
for me. There were a few issues with how RunTest.bat is invoked via CMake,
and how the
Hi,
Pcre has a nice feature, that you can change options by passing special control
strings. E.g: /(*UTF8)a/ makes the pattern an UTF8 pattern. I am sure most
people are not aware of this feature. Its side effect can be used for denial
service attacks, since the valid UTF checks are not
Hi,
Also IMHO for *new* API we shouldn't continue the problems of the old
APIs; that means we should use size_t for the length, start_offset and
offsetcount parameters and the offsets themselves. (If the current code
can't cope, just reuturn an error if length INT_MAX, but then we can
fix
But out of curiosity, how come that pcre_exec can't just do what this
function is supposed to do when it has a JIT-compiled pattern, UTF
checks are not requested, etc.?
The point of the new API is not inventing something which was not possible
before. Instead, it increases the performance of
Dear devs,
I have been thinking for some time, that the point of JIT is offering
outstanding pattern matching performance (and it improved a lot lately) and it
is still used through pcre_exec. So I am planning the add a new interface for
JIT only:
int pcre[16]_jit_exec(const pcre_extra
Hi,
this still looks quite theoretical for me. However, if you come up with a patch
which has negligible performance overhead, I am willing to review.
Regards,
Zoltan
Tom Bishop, Wenlin Institute tan...@wenlin.com írta:
On Sep 17, 2012, at 5:09 PM, Christian Persch (GNOME) c...@gnome.org
We have only a few (two) masks as far as I remember. In practice 16 and 32 bit
modes are basically useless without UTF, since you can only set character types
only for the first 256 code point. And UFT is not likely will go beyond
0x10 in the foreseeable future, since only a small fragment
Hi all,
it is inconvenient for several uses cases, that study sometimes return with
something and sometimes not, and we need to manually allocate a pcre_extra.
Shall we add a flag which forces it to return with a plain, empty, pcre_extra
if it would return with NULL (and there was no error of
írta:
On Sat, 11 Aug 2012, Zoltán Herczeg wrote:
it is inconvenient for several uses cases, that study sometimes return
with something and sometimes not, and we need to manually allocate a
pcre_extra. Shall we add a flag which forces it to return with a
plain, empty, pcre_extra if it would
Hi,
7.0 is really old. We do not support it anymore.
Could you help me in trying to update pcregrep on my Windows system?
I am not a Windows expert myself, but with cmake and mingw (+make) it is easy
to build it. Cygwin probably works as well.
You can find mingw related things here:
Hi Christian,
wow, this is awesome! The UTF16 support was really designed that way, that the
UTF32 support shouldn't be too much trouble, but I suspect there are some
places, where you needed to do a lot of work.
I have some questions:
1) The first / required character data is only 16 bit
If DOTALL is set the result is the same. It seems that is_anchored() is in
action. I think PCRE must not assume such patterns as anchored.
No.
/* .* means start at start or after \n if it isn't in brackets that
may be referenced. */
else if (op == OP_TYPESTAR || op == OP_TYPEMINSTAR
Hi,
I renamed the variable to quit. I hope it will fix the WinCE build.
http://www.exim.org/lurker/message/20120708.164441.53d8f041.hu.html
Regards,
Zoltan
Giuseppe D'Angelo dange...@gmail.com írta:
Hi, a small followup: the JIT doesn't build under WinCE/x86 as well
because the indirect,
Hi,
I have investigated this issue, and in the optimized case, PCRE_STARTLINE is
set, so it searches the first newline. There is a comment for this before
is_startline(...):
/* This is called to find out if every branch starts with ^ or .* so that
first char processing can be done to speed
Hi Daniel,
thank you very much for fixing these issues. I hope JIT is working well on your
system now (If you can share some performance results as well, I am really
interested). I would like to add your changes to the project but the patch has
a strange syntax on my machine:
Hi,
wow, WinCE is still alive?
Anyway, according to this doc these functions should be available everywhere,
but it was never tested, thus the ifdefs:
http://infocenter.arm.com/help/topic/com.arm.doc.ihi0043c/IHI0043C_rtabi.pdf
They can be removed if other platforms like them.
Regards,
PPC with JIT
S/390 witout JIT
AMD64 with JIT
PPC64 with JIT
i686 with JIT
S/390x without JIT
ARMv7 with JIT
ARMv5 with JIT
Awesome, you really have so many systems :)
Thanks for the testing!
Zoltan
--
## List details at https://lists.exim.org/mailman/listinfo/pcre-dev
Hi,
The thing is that PCRE is often built along with other projects. The
more autoconf magic we add, the worst, since those options are
unlikely to be picked up by these projects bundling PCRE. (and I
I totally agree with this. However, adding everything to pcre.h makes it far
less
Hi,
The __has_attribute macro is special in clang. It's defined by the compiler.
Oh, that is probably a misunderstanding. I mean instead of defining this macro
when missing, we should define something with PCRE_ prefix, which is empty if
__has_attribute is not supported.
No, nothing
Hi,
I feel this patch just adds unnecessary complexity to the header file. What
exactly are these optimizations? For buffer overflows, valgrind is the perfect
detection tool with its red zone based detection algorithm. What else can you
do with these macros?
Or better to ask: what is your
101 - 200 of 228 matches
Mail list logo
