[pcre-dev] [Bug 1626] coredump at least since 8.35 with expression [\]\)

https://bugs.exim.org/show_bug.cgi?id=1626 --- Comment #1 from Philip Hazel p...@hermes.cam.ac.uk --- I'm afraid I know nothing about GNU Octave and how it uses libpcre. I have tried to reproduce errors using the pcretest program, and cannot do so. Can you try putting your test pattern into

[pcre-dev] [Bug 1626] New: coredump at least since 8.35 with expression [\]\)

https://bugs.exim.org/show_bug.cgi?id=1626 Bug ID: 1626 Summary: coredump at least since 8.35 with expression [\]\) Product: PCRE Version: 8.37 Hardware: x86-64 OS: Linux Status: NEW Severity: bug

[pcre-dev] [Bug 1638] PCRE Library Call Stack Overflow Vulnerability in match()

https://bugs.exim.org/show_bug.cgi?id=1638 --- Comment #3 from hhjack rubym...@yeah.net --- It does not seem to be a problem of PHP. I have mailed to them lately about this potential match_limit_recursion thing. Here is what they reply: We cannot do much for it. Increase the stack of your server

[pcre-dev] [Bug 1638] PCRE Library Call Stack Overflow Vulnerability in match()

https://bugs.exim.org/show_bug.cgi?id=1638 --- Comment #4 from Zoltan Herczeg hzmes...@freemail.hu --- It does not seem to be a problem of PHP. Trust me it is. It is true, that you found a bug in PCRE, but the stack overflow is caused by not setting the match_limit_recursion variable. This

[pcre-dev] [Bug 1638] PCRE Library Call Stack Overflow Vulnerability in match()

https://bugs.exim.org/show_bug.cgi?id=1638 Zoltan Herczeg hzmes...@freemail.hu changed: What|Removed |Added CC||hzmes...@freemail.hu ---

[pcre-dev] [Bug 1637] Heap overflow / invalid write in fuction pcre_exec

https://bugs.exim.org/show_bug.cgi?id=1637 Philip Hazel p...@hermes.cam.ac.uk changed: What|Removed |Added Status|NEW |RESOLVED

[pcre-dev] [Bug 1638] PCRE Library Call Stack Overflow Vulnerability in match()

https://bugs.exim.org/show_bug.cgi?id=1638 Philip Hazel p...@hermes.cam.ac.uk changed: What|Removed |Added Status|NEW |RESOLVED

[pcre-dev] [Bug 1651] PCRE Library Heap Overflow Vulnerability in find_fixedlength()

https://bugs.exim.org/show_bug.cgi?id=1651 Philip Hazel p...@hermes.cam.ac.uk changed: What|Removed |Added Resolution|--- |FIXED

[pcre-dev] [Bug 1651] New: PCRE Library Heap Overflow Vulnerability in find_fixedlength()

https://bugs.exim.org/show_bug.cgi?id=1651 Bug ID: 1651 Summary: PCRE Library Heap Overflow Vulnerability in find_fixedlength() Product: PCRE Version: 8.37 Hardware: All OS: All Status: NEW

[pcre-dev] [Bug 1554] support subject strings with invalid UTF-8 sequences

https://bugs.exim.org/show_bug.cgi?id=1554 Zoltan Herczeg hzmes...@freemail.hu changed: What|Removed |Added CC||hzmes...@freemail.hu ---

[pcre-dev] [Bug 1642] New: Tests fail due to stack space being limited to 16 M

https://bugs.exim.org/show_bug.cgi?id=1642 Bug ID: 1642 Summary: Tests fail due to stack space being limited to 16 M Product: PCRE Version: 10.10 (PCRE2) Hardware: x86 OS: Linux Status: NEW Severity: bug

[pcre-dev] [Bug 1642] Tests fail due to stack space being limited to 16 M

https://bugs.exim.org/show_bug.cgi?id=1642 Elliot Saba staticfl...@gmail.com changed: What|Removed |Added OS|Linux |MacOS X -- You are

[pcre-dev] [Bug 1642] Tests fail due to stack space being limited to 16 M

https://bugs.exim.org/show_bug.cgi?id=1642 --- Comment #3 from Zoltan Herczeg hzmes...@freemail.hu --- Could you check me how much memory is used for each frame on your system: (gdb) disassemble pcre2_match_8, pcre2_match_8+80 Dump of assembler code from 0x45e630 to 0x45e680:

[pcre-dev] [Bug 1642] Tests fail due to stack space being limited to 16 M

https://bugs.exim.org/show_bug.cgi?id=1642 --- Comment #9 from Zoltan Herczeg hzmes...@freemail.hu --- Should that be the official solution, or is my patch still valuable? Philip should decide this. The sad thing is that these compiler settings are responsible for the performance as well.

[pcre-dev] [Bug 1642] Tests fail due to stack space being limited to 16 M

https://bugs.exim.org/show_bug.cgi?id=1642 Petr Pisar ppi...@redhat.com changed: What|Removed |Added CC||ppi...@redhat.com --- Comment #10

[pcre-dev] [Bug 1642] Tests fail due to stack space being limited to 16 M

https://bugs.exim.org/show_bug.cgi?id=1642 --- Comment #5 from Zoltan Herczeg hzmes...@freemail.hu --- I am sorry that was the public function. The static private recursive function is the match: (gdb) disassemble match Dump of assembler code for function match: 0x005399d2 +0:

[pcre-dev] [Bug 1642] Tests fail due to stack space being limited to 16 M

https://bugs.exim.org/show_bug.cgi?id=1642 --- Comment #7 from Zoltan Herczeg hzmes...@freemail.hu --- That is 3432 (3424 + 1*8) bytes per frame. A wee bit more, I'd say. Actually +2*8 because the return address is also stored on the stack. Anyway, that is huge. Too huge. I just realized that

[pcre-dev] [Bug 1642] Tests fail due to stack space being limited to 16 M

https://bugs.exim.org/show_bug.cgi?id=1642 Zoltan Herczeg hzmes...@freemail.hu changed: What|Removed |Added CC||hzmes...@freemail.hu ---

[pcre-dev] [Bug 1642] Tests fail due to stack space being limited to 16 M

https://bugs.exim.org/show_bug.cgi?id=1642 --- Comment #8 from Elliot Saba staticfl...@gmail.com --- Putting __attribute__((noinline)) on line 579 between the static int and match(REGISTER... doesn't change anything. My ./configure invocation looks like this (stripping out the --prefix and

[pcre-dev] [Bug 1642] Tests fail due to stack space being limited to 16 M

https://bugs.exim.org/show_bug.cgi?id=1642 --- Comment #4 from Elliot Saba staticfl...@gmail.com --- (lldb) disassemble -n pcre2_match_8 [1575/2036] libpcre2-8.0.dylib`pcre2_match_8: 0x10007bf10: pushq %rbp

[pcre-dev] [Bug 1636] PCRE Library Heap Overflow Vulnerability

https://bugs.exim.org/show_bug.cgi?id=1636 hhjack rubym...@yeah.net changed: What|Removed |Added Priority|medium |high -- You are receiving this mail

[pcre-dev] [Bug 1636] New: PCRE Library Heap Overflow Vulnerability

https://bugs.exim.org/show_bug.cgi?id=1636 Bug ID: 1636 Summary: PCRE Library Heap Overflow Vulnerability Product: PCRE Version: N/A Hardware: All OS: All Status: NEW Severity: security

[pcre-dev] [Bug 1636] PCRE Library Heap Overflow Vulnerability

https://bugs.exim.org/show_bug.cgi?id=1636 hhjack rubym...@yeah.net changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #2 from hhjack

[pcre-dev] [Bug 1637] Heap overflow / invalid write in fuction pcre_exec

https://bugs.exim.org/show_bug.cgi?id=1637 --- Comment #1 from Hanno Böck ha...@hboeck.de --- Created attachment 815 -- https://bugs.exim.org/attachment.cgi?id=815action=edit address sanitizer crash trace -- You are receiving this mail because: You are on the CC list for the bug.-- ## List

[pcre-dev] [Bug 1636] PCRE Library Heap Overflow Vulnerability

https://bugs.exim.org/show_bug.cgi?id=1636 Zoltan Herczeg hzmes...@freemail.hu changed: What|Removed |Added CC||hzmes...@freemail.hu ---

[pcre-dev] [Bug 1636] PCRE Library Heap Overflow Vulnerability

https://bugs.exim.org/show_bug.cgi?id=1636 --- Comment #1 from Philip Hazel p...@hermes.cam.ac.uk --- Although this bug is still present in the recent 8.37 release, it has in fact been fixed in the source repository. A number of such bugs have recently been discovered by fuzzers. The bug is also

[pcre-dev] [Bug 1638] New: PCRE Library Call Stack Overflow Vulnerability in match()

https://bugs.exim.org/show_bug.cgi?id=1638 Bug ID: 1638 Summary: PCRE Library Call Stack Overflow Vulnerability in match() Product: PCRE Version: 10.10 (PCRE2) Hardware: All OS: All Status: NEW

[pcre-dev] [Bug 1654] New: PCRE (JIT) does not build on WinCE / x86

https://bugs.exim.org/show_bug.cgi?id=1654 Bug ID: 1654 Summary: PCRE (JIT) does not build on WinCE / x86 Product: PCRE Version: 8.37 Hardware: x86 OS: Windows Status: NEW Severity: bug

[pcre-dev] [Bug 1654] PCRE (JIT) does not build on WinCE / x86

https://bugs.exim.org/show_bug.cgi?id=1654 --- Comment #2 from Giuseppe D'Angelo dange...@gmail.com --- Thanks! Yes, it's still widely used, although these days it goes under other names (Embedded Compact). I guess this can be marked as RESOLVED? -- You are receiving this mail because: You are

[pcre-dev] [Bug 1653] New: Security issue: Overwriting stack content from JIT

https://bugs.exim.org/show_bug.cgi?id=1653 Bug ID: 1653 Summary: Security issue: Overwriting stack content from JIT Product: PCRE Version: 10.10 (PCRE2) Hardware: x86 OS: All Status: NEW Severity: bug

[pcre-dev] [Bug 1653] Security issue: Overwriting stack content from JIT

https://bugs.exim.org/show_bug.cgi?id=1653 Zoltan Herczeg hzmes...@freemail.hu changed: What|Removed |Added Status|NEW |RESOLVED

[pcre-dev] [Bug 1654] PCRE (JIT) does not build on WinCE / x86

https://bugs.exim.org/show_bug.cgi?id=1654 Zoltan Herczeg hzmes...@freemail.hu changed: What|Removed |Added CC||hzmes...@freemail.hu ---

[pcre-dev] [Bug 1616] Line begin anchor fits not at end of text, if the last character is a new line character

https://bugs.exim.org/show_bug.cgi?id=1616 David Gausmann david.gausm...@measx.com changed: What|Removed |Added Status|RESOLVED|VERIFIED -- You are

[pcre-dev] [Bug 1616] Line begin anchor fits not at end of text, if the last character is a new line character

https://bugs.exim.org/show_bug.cgi?id=1616 David Gausmann david.gausm...@measx.com changed: What|Removed |Added Resolution|--- |FIXED

[pcre-dev] [Bug 1665] New: Switch -ql quiet files-with-matches should not show files with matches

https://bugs.exim.org/show_bug.cgi?id=1665 Bug ID: 1665 Summary: Switch -ql quiet files-with-matches should not show files with matches Product: PCRE Version: 10.10 (PCRE2) Hardware: x86-64 OS: Linux

[pcre-dev] [Bug 1669] Numeric categories missing matches

https://bugs.exim.org/show_bug.cgi?id=1669 Hermann Zahnweh eximbugs.apri...@spamgourmet.com changed: What|Removed |Added Status|NEW |RESOLVED

[pcre-dev] [Bug 1670] --color produces invalid UTF-8 for property matches

https://bugs.exim.org/show_bug.cgi?id=1670 Hermann Zahnweh eximbugs.apri...@spamgourmet.com changed: What|Removed |Added Status|NEW |RESOLVED

[pcre-dev] [Bug 1673] PCRE Library Call Stack Overflow Vulnerability in pcre_exec.c

https://bugs.exim.org/show_bug.cgi?id=1673 Philip Hazel p...@hermes.cam.ac.uk changed: What|Removed |Added Resolution|--- |INVALID

[pcre-dev] [Bug 1672] PCRE Library Heap Overflow in compile_regex()

https://bugs.exim.org/show_bug.cgi?id=1672 Philip Hazel p...@hermes.cam.ac.uk changed: What|Removed |Added Resolution|--- |FIXED

[pcre-dev] [Bug 1675] New: FIX for failing test #14

https://bugs.exim.org/show_bug.cgi?id=1675 Bug ID: 1675 Summary: FIX for failing test #14 Product: PCRE Version: 10.20 (PCRE2) Hardware: x86 OS: Windows Status: NEW Severity: bug Priority:

[pcre-dev] [Bug 1676] Test #17 fails

https://bugs.exim.org/show_bug.cgi?id=1676 --- Comment #1 from Roy Ivy III roy.ivy@gmail.com --- * Test #17 fails for the 8-bit library ... -- You are receiving this mail because: You are on the CC list for the bug. -- ## List details at https://lists.exim.org/mailman/listinfo/pcre-dev

[pcre-dev] [Bug 1674] New: CMakeLists: Improper override of CMAKE_C_FLAGS

https://bugs.exim.org/show_bug.cgi?id=1674 Bug ID: 1674 Summary: CMakeLists: Improper override of CMAKE_C_FLAGS Product: PCRE Version: 10.20 (PCRE2) Hardware: x86-64 OS: Windows Status: NEW Severity: bug

[pcre-dev] [Bug 1676] New: Test #17 fails

https://bugs.exim.org/show_bug.cgi?id=1676 Bug ID: 1676 Summary: Test #17 fails Product: PCRE Version: 10.20 (PCRE2) Hardware: x86 OS: Windows Status: NEW Severity: bug Priority: medium

[pcre-dev] [Bug 1674] CMakeLists: Improper override of CMAKE_C_FLAGS

https://bugs.exim.org/show_bug.cgi?id=1674 --- Comment #2 from Roy Ivy III roy.ivy@gmail.com --- I'm happy to help. I've got a fully working build/test process for Windows at rivy/PCRE on github (https://github.com/rivy/PCRE). It uses a git mirror of your PCRE2, and builds both 32-bit and

[pcre-dev] [Bug 1676] Test #17 fails

https://bugs.exim.org/show_bug.cgi?id=1676 --- Comment #5 from Philip Hazel p...@hermes.cam.ac.uk --- No, that's not it. What has happened is that RunTest.bat has not been kept in step with the RunTests Linux script. My fault - I'm afraid I tend to forget. I have commited a new version of

[pcre-dev] [Bug 1674] CMakeLists: Improper override of CMAKE_C_FLAGS

https://bugs.exim.org/show_bug.cgi?id=1674 Philip Hazel p...@hermes.cam.ac.uk changed: What|Removed |Added Resolution|--- |FIXED

[pcre-dev] [Bug 1675] FIX for failing test #14

https://bugs.exim.org/show_bug.cgi?id=1675 Philip Hazel p...@hermes.cam.ac.uk changed: What|Removed |Added Resolution|--- |FIXED

[pcre-dev] [Bug 1672] New: PCRE Library Heap Overflow in compile_regex()

https://bugs.exim.org/show_bug.cgi?id=1672 Bug ID: 1672 Summary: PCRE Library Heap Overflow in compile_regex() Product: PCRE Version: 8.37 Hardware: All OS: All Status: NEW Severity: security

[pcre-dev] [Bug 1673] New: PCRE Library Call Stack Overflow Vulnerability in pcre_exec.c

https://bugs.exim.org/show_bug.cgi?id=1673 Bug ID: 1673 Summary: PCRE Library Call Stack Overflow Vulnerability in pcre_exec.c Product: PCRE Version: 8.37 Hardware: All OS: All Status: NEW

[pcre-dev] [Bug 1669] Numeric categories missing matches

https://bugs.exim.org/show_bug.cgi?id=1669 --- Comment #1 from Philip Hazel p...@hermes.cam.ac.uk --- Oh dear. I thought I replied to this via email the other day. The email message didn't have the Unicode characters in it, so I asked for the code points so that I could test. How did you do these

[pcre-dev] [Bug 1670] --color produces invalid UTF-8 for property matches

https://bugs.exim.org/show_bug.cgi?id=1670 --- Comment #1 from Philip Hazel p...@hermes.cam.ac.uk --- Again, I thought I replied to this via email. As you did not specify -u or --utf when you called pcre2grep, it would not be treating the input as UTF. Intead, it would be processing it byte by

[pcre-dev] [Bug 1676] Test #17 fails

https://bugs.exim.org/show_bug.cgi?id=1676 --- Comment #3 from Roy Ivy III roy.ivy@gmail.com --- After more testing, I've narrowed the regression to the last couple of commits. All tests pass up to SVN@347. The tests pass for 8, 16, and 32 bit libraries, under both 32 and 64 bit compilation.

[pcre-dev] [Bug 1676] Test #17 fails

https://bugs.exim.org/show_bug.cgi?id=1676 --- Comment #4 from Philip Hazel p...@hermes.cam.ac.uk --- Ah! It may be that the tests themselves are at fault. I don't think I've tested without JIT since that commit. I may just have some time later today to look at this (you've happened to hit a few

[pcre-dev] [Bug 1676] Test #17 fails

https://bugs.exim.org/show_bug.cgi?id=1676 --- Comment #2 from Roy Ivy III roy.ivy@gmail.com --- Oddly, when JIT support is enabled. Test #16 fails, and Test #17 passes. -- You are receiving this mail because: You are on the CC list for the bug. -- ## List details at

[pcre-dev] [Bug 1674] CMakeLists: Improper override of CMAKE_C_FLAGS

https://bugs.exim.org/show_bug.cgi?id=1674 --- Comment #1 from Philip Hazel p...@hermes.cam.ac.uk --- I'm glad that somebody is checking out the CMake configuration and compiling the 10.20 release under Windows. I do a basic CMake test under Linux before releasing, but I have no way of testing

[pcre-dev] [Bug 1651] PCRE Library Heap Overflow Vulnerability in find_fixedlength()

https://bugs.exim.org/show_bug.cgi?id=1651 --- Comment #2 from hhjack rubym...@yeah.net --- Please reference this as CVE-2015-5073. -- You are receiving this mail because: You are on the CC list for the bug. -- ## List details at https://lists.exim.org/mailman/listinfo/pcre-dev

[pcre-dev] [Bug 1667] New: PCRE Library Heap Overflow Vulnerability

https://bugs.exim.org/show_bug.cgi?id=1667 Bug ID: 1667 Summary: PCRE Library Heap Overflow Vulnerability Product: PCRE Version: 8.37 Hardware: All OS: All Status: NEW Severity: security

[pcre-dev] [Bug 1667] PCRE Library Heap Overflow Vulnerability

https://bugs.exim.org/show_bug.cgi?id=1667 Philip Hazel p...@hermes.cam.ac.uk changed: What|Removed |Added Resolution|--- |FIXED

[pcre-dev] [Bug 1665] Switch -ql quiet files-with-matches should not show files with matches

https://bugs.exim.org/show_bug.cgi?id=1665 Philip Hazel p...@hermes.cam.ac.uk changed: What|Removed |Added Resolution|--- |FIXED

[pcre-dev] [Bug 1665] Switch -ql quiet files-with-matches should not show files with matches

https://bugs.exim.org/show_bug.cgi?id=1665 --- Comment #2 from Chris Severance bugzilla.sever...@spamgourmet.com --- I had to make a couple of Arch Linux svn packages to test it. Patch works good. -- You are receiving this mail because: You are on the CC list for the bug. -- ## List details at

[pcre-dev] [Bug 1670] New: --color produces invalid UTF-8 for property matches

https://bugs.exim.org/show_bug.cgi?id=1670 Bug ID: 1670 Summary: --color produces invalid UTF-8 for property matches Product: PCRE Version: 10.10 (PCRE2) Hardware: x86-64 OS: Linux Status: NEW Severity:

[pcre-dev] [Bug 1669] New: Numeric categories missing matches

https://bugs.exim.org/show_bug.cgi?id=1669 Bug ID: 1669 Summary: Numeric categories missing matches Product: PCRE Version: 10.10 (PCRE2) Hardware: x86-64 OS: Linux Status: NEW Severity: bug

[pcre-dev] [Bug 1663] New: JIT fails for many matching subpatterns

https://bugs.exim.org/show_bug.cgi?id=1663 Bug ID: 1663 Summary: JIT fails for many matching subpatterns Product: PCRE Version: 8.35 Hardware: x86-64 OS: All Status: NEW Severity: bug Priority:

[pcre-dev] [Bug 1663] JIT fails for many matching subpatterns

https://bugs.exim.org/show_bug.cgi?id=1663 Zoltan Herczeg hzmes...@freemail.hu changed: What|Removed |Added CC||hzmes...@freemail.hu ---

[pcre-dev] [Bug 1663] JIT fails for many matching subpatterns

https://bugs.exim.org/show_bug.cgi?id=1663 Christoph Michael Becker cmbecke...@gmx.de changed: What|Removed |Added Status|NEW |RESOLVED

[pcre-dev] [Bug 1660] New: pcre_exec delivers wrong offsets

https://bugs.exim.org/show_bug.cgi?id=1660 Bug ID: 1660 Summary: pcre_exec delivers wrong offsets Product: PCRE Version: 8.37 Hardware: x86 OS: All Status: NEW Severity: security Priority:

[pcre-dev] [Bug 1660] pcre_exec delivers wrong offsets

https://bugs.exim.org/show_bug.cgi?id=1660 Philip Hazel p...@hermes.cam.ac.uk changed: What|Removed |Added Status|NEW |RESOLVED

[pcre-dev] [Bug 1660] pcre_exec delivers wrong offsets

https://bugs.exim.org/show_bug.cgi?id=1660 Nigel Metheringham ni...@exim.org changed: What|Removed |Added CC||ni...@exim.org

[pcre-dev] [Bug 1676] Test #17 fails

https://bugs.exim.org/show_bug.cgi?id=1676 Roy Ivy III roy.ivy@gmail.com changed: What|Removed |Added Resolution|--- |FIXED Status|NEW

[pcre-dev] [Bug 1704] New: heap-buffer-overflow in compile_branch src/pcre2_compile.c:6323

https://bugs.exim.org/show_bug.cgi?id=1704 Bug ID: 1704 Summary: heap-buffer-overflow in compile_branch src/pcre2_compile.c:6323 Product: PCRE Version: 10.20 (PCRE2) Hardware: x86 OS: Linux

[pcre-dev] [Bug 1705] heap-buffer-overflow in match src/pcre2_match.c:3321:20

https://bugs.exim.org/show_bug.cgi?id=1705 --- Comment #6 from Philip Hazel --- I could add "has \C" to the info, but only in PCRE2. I don't want to do anything to PCRE1 other than mend bugs. Using \C in a UTF-8 match can cause crashes (as documented) so even doing what

[pcre-dev] [Bug 1705] heap-buffer-overflow in match src/pcre2_match.c:3321:20

https://bugs.exim.org/show_bug.cgi?id=1705 --- Comment #5 from Giuseppe D'Angelo --- Isn't there a way either to just know (via full_info) if there's a \C in the pattern? Could it be possible to add it, if not? (My understanding is that by NOT knowing it, it means that in

[pcre-dev] [Bug 1705] New: heap-buffer-overflow in match src/pcre2_match.c:3321:20

https://bugs.exim.org/show_bug.cgi?id=1705 Bug ID: 1705 Summary: heap-buffer-overflow in match src/pcre2_match.c:3321:20 Product: PCRE Version: 10.20 (PCRE2) Hardware: x86 OS: Linux Status: NEW

[pcre-dev] [Bug 1704] heap-buffer-overflow in compile_branch src/pcre2_compile.c:6323

https://bugs.exim.org/show_bug.cgi?id=1704 Philip Hazel changed: What|Removed |Added Resolution|--- |FIXED

[pcre-dev] [Bug 1703] global-buffer-overflow in compile_branch src/pcre2_compile.c:3700

https://bugs.exim.org/show_bug.cgi?id=1703 Philip Hazel changed: What|Removed |Added Status|NEW |RESOLVED

[pcre-dev] [Bug 1705] heap-buffer-overflow in match src/pcre2_match.c:3321:20

https://bugs.exim.org/show_bug.cgi?id=1705 --- Comment #3 from Kostya Serebryany --- (In reply to Giuseppe D'Angelo from comment #2) > However there's no way to exclude \C from PCRE 1, isn't it? I hope Philip can comment. -- You are receiving this mail because: You are on the

[pcre-dev] [Bug 1705] heap-buffer-overflow in match src/pcre2_match.c:3321:20

https://bugs.exim.org/show_bug.cgi?id=1705 Giuseppe D'Angelo changed: What|Removed |Added CC||dange...@gmail.com ---

[pcre-dev] [Bug 1717] New: Classes beginning with POSIX class notation missing elements

https://bugs.exim.org/show_bug.cgi?id=1717 Bug ID: 1717 Summary: Classes beginning with POSIX class notation missing elements Product: PCRE Version: 8.37 Hardware: x86 OS: All Status: NEW

[pcre-dev] [Bug 1718] New: Code and documentation differ on definition of POSIX [:punct:] class

https://bugs.exim.org/show_bug.cgi?id=1718 Bug ID: 1718 Summary: Code and documentation differ on definition of POSIX [:punct:] class Product: PCRE Version: 8.37 Hardware: x86 OS: Windows

[pcre-dev] [Bug 1716] New: pcre_exec return 0 in mips64-octeon-linux-gnu

https://bugs.exim.org/show_bug.cgi?id=1716 Bug ID: 1716 Summary: pcre_exec return 0 in mips64-octeon-linux-gnu Product: PCRE Version: 8.37 Hardware: Other OS: Linux Status: NEW Severity: bug

[pcre-dev] [Bug 1717] Classes beginning with POSIX class notation missing elements

https://bugs.exim.org/show_bug.cgi?id=1717 Philip Hazel changed: What|Removed |Added Resolution|--- |FIXED

[pcre-dev] [Bug 1718] Code and documentation differ on definition of POSIX [:punct:] class

https://bugs.exim.org/show_bug.cgi?id=1718 --- Comment #1 from Philip Hazel --- You are quite right. Thanks for this report. It should be 128. I have patched both the PCRE1 and PCRE2 interpreter code, and informed the JIT maintainer that the JIT code also needs patching. I

[pcre-dev] [Bug 1705] heap-buffer-overflow in match src/pcre2_match.c:3321:20

https://bugs.exim.org/show_bug.cgi?id=1705 --- Comment #7 from Giuseppe D'Angelo --- It's a bit sad -- there's so much code using PCRE1 and UTF and can't be ported just yet to PCRE2. How is the problem of \C solved in PCRE2 anyhow? -- You are receiving this mail because:

[pcre-dev] [Bug 1705] heap-buffer-overflow in match src/pcre2_match.c:3321:20

https://bugs.exim.org/show_bug.cgi?id=1705 --- Comment #8 from Philip Hazel --- PCRE2 has an option PCRE2_NEVER_BACKSLASH_C, which locks out the use of \C. It also has --enable-never-backslash-C, which forces this option on all patterns. I know there's a lot of code

[pcre-dev] [Bug 1703] New: global-buffer-overflow in compile_branch src/pcre2_compile.c:3700

https://bugs.exim.org/show_bug.cgi?id=1703 Bug ID: 1703 Summary: global-buffer-overflow in compile_branch src/pcre2_compile.c:3700 Product: PCRE Version: 10.20 (PCRE2) Hardware: x86 OS: Linux

[pcre-dev] [Bug 1689] Catch up with some of the replacement syntax of the Boost regex engine

https://bugs.exim.org/show_bug.cgi?id=1689 Philip Hazel changed: What|Removed |Added Resolution|--- |FIXED

[pcre-dev] [Bug 1699] New: signed integer overflow in src/pcre2_study.c on "int branchlength"

https://bugs.exim.org/show_bug.cgi?id=1699 Bug ID: 1699 Summary: signed integer overflow in src/pcre2_study.c on "int branchlength" Product: PCRE Version: 10.20 (PCRE2) Hardware: x86-64 OS: Linux

[pcre-dev] [Bug 1697] Incorrect compilation of classes containing ucase mnemonics and properties

https://bugs.exim.org/show_bug.cgi?id=1697 Philip Hazel changed: What|Removed |Added Status|NEW |RESOLVED

[pcre-dev] [Bug 1699] signed integer overflow in src/pcre2_study.c on "int branchlength"

https://bugs.exim.org/show_bug.cgi?id=1699 Philip Hazel changed: What|Removed |Added Status|NEW |RESOLVED

[pcre-dev] [Bug 1679] New: Ability to explicitly specify what to capture (feature request)

https://bugs.exim.org/show_bug.cgi?id=1679 Bug ID: 1679 Summary: Ability to explicitly specify what to capture (feature request) Product: PCRE Version: N/A Hardware: All OS: All Status: NEW

[pcre-dev] [Bug 1654] PCRE (JIT) does not build on WinCE / x86

https://bugs.exim.org/show_bug.cgi?id=1654 henrik.h...@aol.de changed: What|Removed |Added Version|N/A |8.37 -- You are receiving this mail

[pcre-dev] [Bug 1679] Ability to explicitly specify what to capture (feature request)

https://bugs.exim.org/show_bug.cgi?id=1679 --- Comment #1 from henrik.h...@aol.de --- I think you should be able to reference both the original and the modified capture string in the regular expression to be able to piece a capture string together at a later position. -- You are receiving this

[pcre-dev] [Bug 1654] PCRE (JIT) does not build on WinCE / x86

https://bugs.exim.org/show_bug.cgi?id=1654 --- Comment #3 from Zoltan Herczeg hzmes...@freemail.hu --- Yes, we can close this bug. Please check first that it works (I cannot). -- You are receiving this mail because: You are on the CC list for the bug. -- ## List details at

[pcre-dev] [Bug 1679] Ability to explicitly specify what to capture (feature request)

https://bugs.exim.org/show_bug.cgi?id=1679 Zoltan Herczeg hzmes...@freemail.hu changed: What|Removed |Added CC||hzmes...@freemail.hu ---

[pcre-dev] [Bug 1679] Ability to explicitly specify what to capture (feature request)

https://bugs.exim.org/show_bug.cgi?id=1679 --- Comment #3 from henrik.h...@aol.de --- Would there arrive confusion about memory responsibility if just new strings were allocated and be returned when a capture string is modified, or unacceptable work to be done on a regular basis for a feature

[pcre-dev] [Bug 1680] Creating the intersection of two regular expressions

https://bugs.exim.org/show_bug.cgi?id=1680 --- Comment #1 from Philip Hazel p...@hermes.cam.ac.uk --- I don't think ^a\d+b$ is the intersection of ^a\d+ and \d+b$ if you mean matches strings that match each separate pattern. I think the intersection is ^a\d+(.+\d+)?b$ because the first means

[pcre-dev] [Bug 1679] Ability to explicitly specify what to capture (feature request)

https://bugs.exim.org/show_bug.cgi?id=1679 --- Comment #4 from Philip Hazel p...@hermes.cam.ac.uk --- Currently, pcre2_substitute() gives access only to captured substrings in the replacement string. It would be possible to allow it to access the MARK string, in which case you could do something

[pcre-dev] [Bug 1679] Ability to explicitly specify what to capture (feature request)

https://bugs.exim.org/show_bug.cgi?id=1679 --- Comment #6 from Philip Hazel p...@hermes.cam.ac.uk --- Allowing an escape in a *MARK name would be incompatible with Perl, but it could be done using a non-default PCRE2 option. That is a separate issue to allowing for ${*mark} in substitutions, of

[pcre-dev] [Bug 1679] Ability to explicitly specify what to capture (feature request)

https://bugs.exim.org/show_bug.cgi?id=1679 --- Comment #8 from henrik.h...@aol.de --- I have added interpretation of ${*MARK} to pcre2_substitute() and committed the patch. It seems to work OK. It's great that it could be implemented so fast. Now I have to wait for months or years till it's

[pcre-dev] [Bug 1679] Ability to explicitly specify what to capture (feature request)

https://bugs.exim.org/show_bug.cgi?id=1679 Philip Hazel p...@hermes.cam.ac.uk changed: What|Removed |Added Status|NEW |RESOLVED

  1   2   3   4   5   6   7   8   9   10   >