Hi Giuseppe,
The first one: the whole string is checked if PCRE_NO_UTF8_CHECK is not passed.
It can be really costly if subject is long (several Mbytes). Malformed strings
can cause PCRE to read bytes before the beginning or after the end of the
subject string and this can lead to undesired
Hi,
Thank you very much! Another one for the list on the homepage ;-)
Sure, please check http://sljit.sourceforge.net/pcre.html if the line is ok for
you.
Regards,
Zoltan
--
## List details at https://lists.exim.org/mailman/listinfo/pcre-dev
Hi,
You mean:
7. Some cosmetic changes to the code to make life easier when compiling it
as part of something else:
(a) Change DEBUG to PCRE_DEBUG.
(b) In pcre_compile(), rename the member of the branch_chain structure
called current as current_branch, to prevent a
Hi,
Not a stupid question. Thanks for asking it. Darn. I want this
functionality for pcretest. I do not want to modify the API for
pcre_exec. Is there any other way I can achieve this? (I was slightly
worried when I implemented what I did, but obviously not worried enough.
I must remember to
Ah! No problem! I can easily make that happen in pcretest to get this
information. I will sort that out.
(Just to be absolutely sure: the callback will not be called if, for
example, JIT has compiled for normal match, but not partial, and a
partial match is tried. Is that right? I assume
Hi,
yeah, it is a typo, thanks for reporting it. I am really grateful that you
continually test PCRE!
pcre_jit_compile.c:7146
return ((executable_functions
*)executable_funcs)-executable_sizes[PCRE_STUDY_JIT_COMPILE];
PCRE_STUDY_JIT_COMPILE should be JIT_COMPILE
However, since now we have 3
Hi All,
partial matching is added to PCRE-JIT, all tests are passed. We also identified
some issues with the main library which will be fixed as a separate works. The
current implementation is bug compatible with PCRE.
To use partial matching in JIT, you need to compile its corresponding
Hi Rhodri,
This might be a basic question but if pcre_free is a function pointer is
this used to supply a function pointer to the pcre code to be called when
the pcre dll needs to delete the compiled pcre structure returned from
pcre_compile? Am I correct to assume that I need to free the
Hi,
I did testing on various configurations and various environments and the latest
rev passes all. I hope we don't really need to touch anything before the
release.
Regards,
Zoltan
Philip Hazel p...@hermes.cam.ac.uk írta:
I have just put 8.30-RC1 onto the FTP site:
Hi Naden,
I am afraid you misunderstand something here. In PCRE partial matching never
prevent full matches. All your tests cases work as expected (Note that (?!b)
matches to any empty string). But you want a complete behaviour change for your
specific use case which would break compatibility,
Hi Andy,
I cannot help you in those compiler issues, but I can compile you a pcretest
with cmake + mingw 32 or 64, just tell me the needed features (utf, ucp, jit)
in privately.
Regards,
Zoltan
Andy a...@asiteaboutnothing.net írta:
Greetings!
I wonder if one of you could share the magic
I think this is an excellent idea. If Philip also supports it, I will do this.
Regards,
Zoltan
Ralf Junker ralfjun...@gmx.de írta:
On 05.01.2012 08:39, Zoltán Herczeg wrote:
One detriment to a combined 8+16 library is that it may be too easy
to accidentally mis-code to the wrong 8/16 API
Hi,
Done. Thank you for the idea.
Regards,
Zoltan
Philip Hazel p...@hermes.cam.ac.uk írta:
On Thu, 5 Jan 2012, Zoltán Herczeg wrote:
I think this is an excellent idea. If Philip also supports it, I will do
this.
We do of course already pick up these errors, but only at runtime.
Earlier
Hi Petr,
thank you for the testing. Actually the PPC error was done by me, and I also
noticed a few days ago (I changed a value to pcre_uint32 from long int, which
is 64 bit long). There was an other error in JIT revealed on ARM (signed /
unsigned load half issue), and you likely see it on
I cannot see any change in library SONAME number. This number should change
to reflect the function has been removed from API.
No idea. The source file is surely removed from the library.
Regards,
Zoltan
--
## List details at https://lists.exim.org/mailman/listinfo/pcre-dev
Hi,
Done. I think this is the best solution after all since it does not break
compatibility and it is a clear design.
Regards,
Zoltan
Philip Hazel p...@hermes.cam.ac.uk írta:
On Tue, 3 Jan 2012, Zoltán Herczeg wrote:
Philip, if you agree, I will duplicate the structures.
OK, go ahead
Hi,
I forgot to click on reply all...
The reason for single structures is maintainability. Well, what do
you think about unions? Every char* pointer would be replaced to a
union with both char* and short*pointers. Would that help?
It would probably help, but it would not detect wrong
Hi,
Right now pcre16_version() and 16-bit PCRE error messages are all 8-bit.
Do you plan to change these to 16-bit?
No. There is no nice way to define 16 bit strings.
const char *str = String
converted to
const pcre_uchar str[] = { PCRE_S, PCRE_t, PCRE_r, PCRE_i, PCRE_n, PCRE_g, 0 };
This
Hi,
FYI: pcre_info has been considered obsolote for 10 years, and Philip decided to
drop it. All applications must use pcre_fullinfo exclusively from now on.
Hopefully there won't be any major breakages.
Regards,
Zoltan
--
## List details at https://lists.exim.org/mailman/listinfo/pcre-dev
Hi,
do you know that PCRE now has an sljit based JIT compiler? Machine code runs
much faster than the normal pcre_exec and there is no such restrictions such as
with the DFA engine.
Regards,
Zoltan
Bogdan Harjoc har...@gmail.com írta:
Snort uses PCRE to filter traffic through about 3200
Hi,
finally works on PPC :)
Thanks Petr!
Regards,
Zoltan
Petr Pisar ppi...@redhat.com írta:
On Mon, Dec 05, 2011 at 12:45:44PM +, Philip Hazel wrote:
I have just put a Release Candidate for 8.21 on the FTP site:
8.21-RC1 compiles (--enable-utf8 --enable-unicode-properties) and passes
Hi Craig,
Here's what I've found in my research:
OS X: malloc_size()
glibc: malloc_usable_size()
Windows: _msize()
I think solaris libc has one too, but I'm not sure what it is.
In any case, it definitely affects portability (makes it more work) if
you want to use such functionality.
Hi Sheri,
this memory size of the executable code is an interesting idea. Do you need it
for statistical purposes? Actually the JIT does not store the size of the
executable size (and you still cannot save and restore this block), only the
executable allocator knows the size.
The easiest way
Craig Silverstein csilv...@google.com írta:
} (funny, that although the allocators know everything about any
} memory block, they don't share it with the userland).
If your goal is to find out how big a block allocated by malloc() is,
most libc's I know support this. But I'm not sure that's
Hi,
I noticed that the JIT stack handling cause a lot of misunderstanding. It was
my fault, I thought the CONTROLLING THE JIT STACK part of pcrejit.3 man page
was enough. I realized the concept (reasons) of the JIT stack are missing.
Probably the best way to explain this is through questions:
Hi Ralf,
(sorry for misspelling your name before)
It is not recommended to allocate a stack in pcre_jit_callback() function since
it is an expensive OS operation, and you still need to free it somehow (as you
guessed). Its primary purpose is returning the stack for the current thread if
you
Hi Ralph,
alloca is a stupid workaround for forcing Windows to call its own chkstk (check
stack or something) function. Windows allows the stack growing only in page
sizes, usually 4k. So if you allocate, lets say 64k stack, chkstk goes down and
touches all 4k pages one by one, and Windows
Hi Sheri,
if I understand you correctly, you have a binary program that you cannot
change. However, you can recompile the pcre lib for this program. In that case
you could just change pcreposix.c a little:
typedef struct {
void *re_pcre;
size_t re_nsub;
size_t re_erroffset;
} regex_t;
201 - 228 of 228 matches
Mail list logo
