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
On Sat, 29 Nov 2014, Maël Hörz wrote:
I noticed an issue so far with CMAKE under Windows and Visual Studio 2013:
PCRE2_BUILD_PCRE2_8 = ON works, but switching on PCRE2_BUILD_PCRE2_16
and PCRE2_BUILD_PCRE2_32, too, causes function prototype conflicts (same
name exported/defined several
On Sat, 29 Nov 2014, Maël Hörz wrote:
Wouldn't it make sense to keep/reintroduce PCRE2_JAVASCRIPT_COMPAT as a
combination/oring of PCRE2_ALT_BSUX, PCRE2_ALLOW_EMPTY_CLASS, and
PCRE2_MATCH_UNSET_BACKREF?
I abolished JAVASCRIPT_COMPAT for two reasons: (1) It caused some people
to think it
pcre2_get_ovector_count returns a uint32_t and callout_number is
uint32_t, but the number parameter for the following functions is
unsigned int:
pcre2_substring_copy_bynumber
pcre2_substring_get_bynumber
pcre2_substring_length_bynumber
Shouldn't that be the same types?
int
On Sun, 30 Nov 2014, I wrote:
On Sat, 29 Nov 2014, Maël Hörz wrote:
I also noticed that there is still an option PCRE2_SUPPORT_BSR_ANYCRLF
that is separate from PCRE2_SUPPORT_UNICODE.
I will look into that.
Please ignore that comment. I mis-read the line above as
I noticed an issue so far with CMAKE under Windows and Visual Studio 2013:
PCRE2_BUILD_PCRE2_8 = ON works, but switching on PCRE2_BUILD_PCRE2_16
and PCRE2_BUILD_PCRE2_32, too, causes function prototype conflicts (same
name exported/defined several times).
Can you post the errors? I have no
Can you post the errors? I have no access to any Windows systems,
but from the errors I might be able to work out what is going on.
Better still if you can post a fix. :-) [Or send it to me direct.]
It took me a while to find out the cause since I am not that familiar
with CMAKE and some
On Sun, 30 Nov 2014, Maël Hörz wrote:
pcre2_get_ovector_count returns a uint32_t and callout_number is uint32_t, but
the number parameter for the following functions is unsigned int:
pcre2_substring_copy_bynumber
pcre2_substring_get_bynumber
pcre2_substring_length_bynumber
Shouldn't
It compiles that way, and
assuming no other code references this from another shared library, we
should be good.
I was referring to this code comment:
/* Private external functions. These are internal functions that are
called
from modules other than the one in which they are defined. They
On Sun, 30 Nov 2014, Maël Hörz wrote:
It compiles that way, and
assuming no other code references this from another shared library, we
should be good.
I was referring to this code comment:
/* Private external functions. These are internal functions that are called
from modules other
--- You are receiving this mail because: ---
You are on the CC list for the bug.
http://bugs.exim.org/show_bug.cgi?id=1554
Summary: support subject strings with invalid UTF-8 sequences
Product: PCRE
Version: N/A
Platform: All
OS/Version:
12 matches
Mail list logo
