--- You are receiving this mail because: ---
You are on the CC list for the bug.
http://bugs.exim.org/show_bug.cgi?id=1316
Summary: Allocation failure in SLJIT doesn't release the
allocator lock?
Product: PCRE
Version: 8.31
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
The idea is this: the programme that's using the pcre32 API wants to
use it on some data it has. That data isn't only used for matching
however, ie it may also be displayed, etc, and the programme has
therefore stored some flags into the unused-by-UTF-32 high bits of the
Wow, wow... stop it
On Fri, 9 Nov 2012, Tom Bishop, Wenlin Institute wrote:
Currently, PCRE sets a horrible precedent for a protocol.
PCRE_NO_UTF32_CHECK has two meanings at the same time: don't check
the input, since we already know it's valid UTF-32 and mask the
input, since it's not UTF-32, it's really
Wow, wow... stop it right there is good advice. It may seem impolite
advice,
especially given that the masking feature was introduced, with good
intentions,
by the same person who did the hard work of implementing 32-bit support,...
I did not mean to be impolite and I appologize for the
On Nov 9, 2012, at 11:24 AM, Philip Hazel p...@hermes.cam.ac.uk wrote:
Christian is going to work on implementing a runtime option that
explicitly requests masking. Apparently he intends to use this facility
himself. We will document it with suitable warnings (such as you put in
your
