Description of problem: pcre package comes configured with utf-8 support, but with no unicode properties enabled. Version-Release number of selected component (if applicable): 6.6-2 How reproducible: always Steps to Reproduce: 1.install pcre package from repository Actual results: > pcretest -C PCRE version 6.6 06-Feb-2006 Compiled with UTF-8 support No Unicode properties support Newline character is LF Internal link size = 2 POSIX malloc threshold = 10 Default match limit = 10000000 Default recursion depth limit = 10000000 Match recursion uses stack Expected results: PCRE version 6.6 06-Feb-2006 Compiled with UTF-8 support Unicode properties support Newline character is LF Internal link size = 2 POSIX malloc threshold = 10 Default match limit = 10000000 Default recursion depth limit = 10000000 Match recursion uses stack Additional info: add configure option --enable-unicode-properties
Same problem here, we need it badly with the Zend Framework for sites with non-latin charsets.
Is the about to be fixed, so the need for an overlay packages repository would be no longer needed ?
No still not fixed. RH has marked it as a feature (it is?!?) request.
We've exactly the same problem here, in order to use the search engine delivered with TYPOlight webCMS (PHP), we really need that feature enabled. I also wonder that this isn't already enabled for a long time - or is Red Hat less unicode interested as Fedora is for ages now? I'm adding RHEL Product and Program Management on Cc to get this maybe solved for RHEL 5.3 as it seems to be a tiny and minor change to me (and I also hope, that the e-mail address isn't just a dummy one). I'm adding Joe as he's the PHP downstream maintainer and also should know the issue/the missing feature in PHP.
*** Bug 461712 has been marked as a duplicate of this bug. ***
Is may hope that this issue is fixed in the 5.3 release?
Not that I could see it. Gerwin, you may want to ask your salesguy as well to get this priorized.
For your info: I escalated the support ticket about this ,to high.
This request was evaluated by Red Hat Product Management for inclusion, but this component is not scheduled to be updated in the current Red Hat Enterprise Linux release. If you would like this request to be reviewed for the next minor release, ask your support representative to set the next rhel-x.y flag to "?".
This page details how to build a fixed PCRE with Unicode support, or you can just download the RPM that has been already compiled for Centos 5.2 (=RHEL 5.2) http://gaarai.com/2009/01/31/unicode-support-on-centos-52-with-php-and-pcre/
Can the "Red Hat Product Management" explain why it doesn't want to enable the unicode properties? Don't it think enabling utf8 support and not unicode properties is contradictory?
wow, it's been two years now... this is an easily fixed issue, that still hasn't been rectified in two years? I'm glad I moved on to Ubuntu.
I've cross-filed this issue as Service Request 2041330.
Technical note added. If any revisions are required, please edit the "Technical Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. New Contents: Unicode properties have been enabled to support \p{..}, \P{..}, and \X escape sequences.
Please test for php bug38600. Our internal build with unicode properties caused this bug to hit again. We needed extra patch to address this infinite loop in pcre. Testing code for the issue is in http://bugs.php.net/bug.php?id=38600 Please test before releasing new pcre.
(In reply to comment #33) > Please test for php bug38600. Our internal build with unicode properties caused > this bug to hit again. We needed extra patch to address this infinite loop in > pcre. > > Testing code for the issue is in http://bugs.php.net/bug.php?id=38600 > > Please test before releasing new pcre. I can confirm the pcre-6.6-6.el5 does not terminate on compiling the pattern: #!/bin/sh PATTERN='/(?<!\w)(0x[\p{N}]+[lL]?|[\p{Nd}]+(e[\p{Nd}]*)?[lLdDfF]?)(?!\w)/' TEXT='bla bla bla' printf "${PATTERN}\\n${TEXT}\\n" | pcretest
Created attachment 473346 [details] Fix for looping on pattern compilation in non-UTF-8 I believe I found fix for the loop problem. This attachment should fix it.
Created attachment 473347 [details] Test case for the loop problem This C program tests the loop problem. If the problem is fixed, the program returns with success code in finite time. Otherwise it never halts.
The infinite loop problem is addressed in new bug #669413. Thanks for careful testing.
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHEA-2011-0022.html