Re: [pcre-dev] Bugzilla at bugs.exim.org

Autor: Andrew Ho
Data:
A: PCRE Developers
Assumpte: Re: [pcre-dev] Bugzilla at bugs.exim.org

Hello,

NL>The admin of the sf.net project can export
NL>the bugs by fetching the following URL:
NL>http://sourceforge.net/export/xml_export.php?group_id=10194

I've attached the XML file in question.

Also, if anybody has a SourceForge.net account (free, and, in my
experience, spam-free), I can set them up as an admin on the project to
manage file releases, export bugs, etc.

NL>Also: can you please link
NL>http://bugs.exim.org/enter_bug.cgi?product=PCRE from pcre.org?

This is now also done, under the "contact" section.

By the way, is it possible to grant read-only access to Bugzilla for
users without an account? It would be nice to have a "known bugs" link.

Humbly,

Andrew

----------------------------------------------------------------------
'Twas brillig, and the slithy toves                         Andrew Ho
  Did gyre and gimble in the wabe.                  andrew@???
  All mimsy were the borogoves,
  And the mome raths outgrabe.          http://www.zeuscat.com/andrew/
----------------------------------------------------------------------

<?xml version='1.0' encoding='ISO-8859-1'?>

<!DOCTYPE project_export SYSTEM "http://sourceforge.net/export/sf_project_export_0.1.dtd">
<project_export>

<artifacts>

<artifact>
    <field name="artifact_id">1695147</field>
    <field user_id="1144855" name="submitted_by">moltonel</field>
    <field user_id="100" name="assigned_to">nobody</field>
    <field name="priority">5</field>
    <field name="status">Open</field>
    <field name="resolution">None</field>
    <field name="summary">pcre_exec doesn't return PCRE_ERROR_BADUTF8 for invalid UTF8</field>
    <field name="open_date">1175794297</field>
    <field name="artifact_type">Feature Requests</field>
    <field name="category">None</field>
    <field name="artifact_group_id">None</field>
    <field name="details">I found some invalid UTF8 chars that do not trigger a PCRE_ERROR_BADUTF8 error when found in the subject string :

\xF4\x92\x94\x95
\xED\xB2\x94

Tested with verion 6.6 and 7.0

See table 3-6 of http://www.unicode.org/versions/Unicode4.0.0/ch03.pdf for valid UTF8 chars.


Because of this bug in libpcre and other implementations I tried, I went and implemented my own is_utf8() function (plus unit test). I'd be happy to send you the function or the unit test if you want it.</field>
    <field name="artifact_messages">
<message>
        <field name="adddate">1177001805</field>
        <field name="user_name">moltonel</field>
        <field name="body">Logged In: YES 
user_id=1144855
Originator: YES

Please check again, I dont think I got this wrong. I am not talking about unassigned code points.

Unless unicode 5 changed the definition of a &#34;well-formed UTF-8 byte sequence&#34;, but as far as I know new unicode versions only assign new code points or refine character properties.
I couldn't find apropriate version 5 documentation, but I'll assume in the rest of my comment that the v4 pdf I gave is still valid for v5 (if you can point me to complete version 5 documentation that proves me wrong, go ahead).


According to the table mentioned above :
* the byte sequence \xED\xB2\x94 is invalid because the second byte is not between \x80 and \x9F.
* The byte sequence \xF4\x92\x94\x95 is invalid because the second byte is not between \x80 and \x8F.

Looks like you're just checking wether the second byte is between \x80 and \xBF, but sometimes it is more restricted !


BTW, I came upon this bug because postgres rejects this data, while you accept it. The postgres UTF8 functions are too complicated for my needs, though.</field>
</message>

<message>
        <field name="adddate">1176817442</field>
        <field name="user_name">nobody</field>
        <field name="body">Logged In: NO 

Oh, forgot to add that the above comment came from Philip Hazel.</field>
</message>

<message>
        <field name="adddate">1176817369</field>
        <field name="user_name">nobody</field>
        <field name="body">Logged In: NO 

I don't know who set up this buglist for PCRE, but it was not the official maintainer.

This bug is invalid. I'm afraid you have confused &#34;invalid UTF-8&#34; with &#34;unassigned Unicode point&#34;. PCRE checks for the former, not for the latter. The strings you list above are valid UTF-8 sequences for unassigned code points. Incidentally, PCRE 7.0 uses Unicode 5.</field>
</message>
</field>
</artifact>
<artifact>
    <field name="artifact_id">1688448</field>
    <field user_id="100" name="submitted_by">nobody</field>
    <field user_id="100" name="assigned_to">nobody</field>
    <field name="priority">5</field>
    <field name="status">Open</field>
    <field name="resolution">None</field>
    <field name="summary">Lookbehind assert (?&#60;=) error in pcre_dfa_exec</field>
    <field name="open_date">1174920430</field>
    <field name="artifact_type">Feature Requests</field>
    <field name="category">None</field>
    <field name="artifact_group_id">None</field>
    <field name="details">This can work:
////////////////
  re&#62; /(?&#60;=a)b/
data&#62; ab
 0: b
///////////////

But this can not:
///////////////
  re&#62; /(?&#60;=a)b/
data&#62; a/P/D
No match
data&#62; b/R/P/D
No match
///////////////

I think the second one should also get matched.</field>
    <field name="artifact_messages">
<message>
        <field name="adddate">1176817578</field>
        <field name="user_name">nobody</field>
        <field name="body">Logged In: NO 

I'm afraid you are wrong. The lookbehind asserts that there must be an &#34;a&#34; before the &#34;b&#34;. In your second example there is no &#34;a&#34; before the &#34;b&#34;. (Comment by PH)</field>
</message>
</field>
</artifact>
<artifact>
    <field name="artifact_id">1688293</field>
    <field user_id="100" name="submitted_by">nobody</field>
    <field user_id="100" name="assigned_to">nobody</field>
    <field name="priority">5</field>
    <field name="status">Open</field>
    <field name="resolution">None</field>
    <field name="summary">PHP Segmentation Fault on PCRE preg_match_all()</field>
    <field name="open_date">1174910037</field>
    <field name="artifact_type">Feature Requests</field>
    <field name="category">None</field>
    <field name="artifact_group_id">None</field>
    <field name="details">Good Morning,
we're getting a Segmentation Fault error calling preg_match_all() in PHP 4.4.6 (that uses PCRE 7.0).

Perhaps you can help us solving this problem. I post the PHP BUG url:

http://bugs.php.net/bug.php?id=40909

Thank you in advice
Adriano C.</field>
    <field name="artifact_messages">
<message>
        <field name="adddate">1176291207</field>
        <field name="user_name">nobody</field>
        <field name="body">Logged In: NO 

Another related bug:
http://bugs.php.net/bug.php?id=41050</field>
</message>
</field>
</artifact>
<artifact>
    <field name="artifact_id">1673412</field>
    <field user_id="1529578" name="submitted_by">ruudboon</field>
    <field user_id="100" name="assigned_to">nobody</field>
    <field name="priority">5</field>
    <field name="status">Open</field>
    <field name="resolution">None</field>
    <field name="summary">PCRE Bug or Smarty Bug?</field>
    <field name="open_date">1173010421</field>
    <field name="artifact_type">Feature Requests</field>
    <field name="category">None</field>
    <field name="artifact_group_id">None</field>
    <field name="details">Hi,

After upgrading to version 7.0 of PCRE smarty for PHP stops working. The only way to get it working again is downgrading PCRE. 
Smarty stop responding on this line :
preg_match_all('~\|(@?\w+)((?&#62;:(?:'. $this-&#62;_qstr_regexp . '|[^|]+))*)~', '|' . $modifier_string, $_match);
There's a topic on http://www.phpinsider.com/smarty-forum/viewtopic.php?t=10467
Is this problem smarty related or PCRE? S
marty works fine with version PCRE 6.6_1. It's running on freebsd6 with apache2 and php5.2

With regards,

Ruud Boon
</field>
</artifact>
<artifact>
    <field name="artifact_id">1647470</field>
    <field user_id="780533" name="submitted_by">apostolo</field>
    <field user_id="100" name="assigned_to">nobody</field>
    <field name="priority">7</field>
    <field name="status">Open</field>
    <field name="resolution">None</field>
    <field name="summary">Subroutine bug with certain patterns.</field>
    <field name="open_date">1170108576</field>
    <field name="artifact_type">Feature Requests</field>
    <field name="category">None</field>
    <field name="artifact_group_id">None</field>
    <field name="details">Below is the pcretest output (7.0 version):

* The first pattern works correctly: a|(ab) matches both 'a' and 'ab'.

* The second pattern also works correctly:
 (a|(ab)) | ( y(a|(ab)) )
matches 'a', 'ab', 'ya', 'yab'.

* Trouble starts with the third pattern, when a subroutine is used for a|(ab): now the string 'yab' doesn't match (but should).

* Trouble remains when using a named subroutine.

* All's fixed if the a|(ab) is changed to (ab?).

Seems like a lookahead problem in the context of subroutines, with maybe caching in the mix...


PCRE version 7.0 18-Dec-2006

/^(a|(ab))$/
a
 0: a
 1: a
ab
 0: ab
 1: ab
 2: ab

/^((a|(ab))|(y(a|(ab))))$/
a
 0: a
 1: a
 2: a
ab
 0: ab
 1: ab
 2: ab
 3: ab
ya
 0: ya
 1: ya
 2: &#60;unset&#62;
 3: &#60;unset&#62;
 4: ya
 5: a
yab
 0: yab
 1: yab
 2: &#60;unset&#62;
 3: &#60;unset&#62;
 4: yab
 5: ab
 6: ab

/^((a|(ab))|(y(?1)))$/
a
 0: a
 1: a
 2: a
ab
 0: ab
 1: ab
 2: ab
 3: ab
ya
 0: ya
 1: ya
 2: &#60;unset&#62;
 3: &#60;unset&#62;
 4: ya
yab
No match

/^((?P&#60;PAT&#62;(a|(ab)))|(y(?P&#62;PAT)))$/
a
 0: a
 1: a
 2: a
 3: a
ab
 0: ab
 1: ab
 2: ab
 3: ab
 4: ab
ya
 0: ya
 1: ya
 2: &#60;unset&#62;
 3: &#60;unset&#62;
 4: &#60;unset&#62;
 5: ya
yab
No match

/^((ab?)|(y(?1)))$/
a
 0: a
 1: a
 2: a
ab
 0: ab
 1: ab
 2: ab
ya
 0: ya
 1: ya
 2: &#60;unset&#62;
 3: ya
yab
 0: yab
 1: yab
 2: &#60;unset&#62;
 3: yab</field>
    <field name="artifact_messages">
<message>
        <field name="adddate">1176818476</field>
        <field name="user_name">nobody</field>
        <field name="body">Logged In: NO 

Here is a quote from the pcrepattern man page: &#34;Like recursive subpatterns, a &#34;subroutine&#34; call is always treated as an atomic group. That is, once it has matched some of the subject string, it is never re-entered, even if it contains untried alternatives and there is a subsequent matching failure.&#34; That is why #3 fails: having matched &#34;a&#34; it cannot be re-entered to try for &#34;ab&#34;. (Comment by PH)</field>
</message>
</field>
    <field name="artifact_history">
<history>
        <field name="field_name">priority</field>
        <field name="old_value">5</field>
        <field name="entrydate">1170108606</field>
        <field name="mod_by">apostolo</field>
</history>
</field>
</artifact>
<artifact>
    <field name="artifact_id">1633009</field>
    <field user_id="334898" name="submitted_by">bertranddb</field>
    <field user_id="100" name="assigned_to">nobody</field>
    <field name="priority">5</field>
    <field name="status">Open</field>
    <field name="resolution">None</field>
    <field name="summary">BUG using the pattern &#34;\s&#34;</field>
    <field name="open_date">1168507348</field>
    <field name="artifact_type">Feature Requests</field>
    <field name="category">None</field>
    <field name="artifact_group_id">None</field>
    <field name="details">Tested with PCRE 6.7 -&#62; 4.5

when replacing an utf-8 string containing the character '&#195;&#160;' (hex: c3a0)
With the function preg_replace, and the pattern '\s', it changes the
second byte of this character.

Using the pattern ' \t\f\r\n' which is supposed to be the same as \s it
works perfectly.

I have tried with other utf-8 characters and it seems to work.

Reproduce code:
---------------
&#60;?
$text = utf8_encode(&#34;this is a test &#195;&#160;t&#34;);
echo bin2hex($text).&#34;\r\n&#34;;
$text1 = preg_replace(&#34;'([\t\f\r\n])+'&#34;, &#34; &#34;, $text);
echo bin2hex($text1).&#34;\r\n&#34;;
echo $text1.&#34;\r\n&#34;;;
$text2 = preg_replace(&#34;'([\s])+'&#34;, &#34; &#34;, $text);
echo bin2hex($text2).&#34;\r\n&#34;;
echo $text2;
?&#62;</field>
    <field name="artifact_messages">
<message>
        <field name="adddate">1176818606</field>
        <field name="user_name">nobody</field>
        <field name="body">Logged In: NO 

This cannot be a PCRE bug because PCRE does not provide replacement facilities; they are left to the calling application.</field>
</message>
</field>
</artifact>
<artifact>
    <field name="artifact_id">1420888</field>
    <field user_id="1423129" name="submitted_by">cestith</field>
    <field user_id="100" name="assigned_to">nobody</field>
    <field name="priority">7</field>
    <field name="status">Open</field>
    <field name="resolution">None</field>
    <field name="summary">non-Perl compatible behavior with nested quantifiers</field>
    <field name="open_date">1138738878</field>
    <field name="artifact_type">Feature Requests</field>
    <field name="category">None</field>
    <field name="artifact_group_id">None</field>
    <field name="details">This:


# php
&#60;?php
$foo = &#34;a \n&#34;;
if ( preg_match ( '/\w++\b \n/', $foo ) ) {
   print &#34;matched!\n&#34;;
} else {
   print &#34;didn't match!\n&#34;;
}
?&#62;


... and this:


echo 'a ' | grep-cvs -P '\w++\b \n'



behave differently than this:

 echo 'a ' | perl -e  '$_ = &#60;&#62;; print if m/\w++\b \n/'



The Perl thing to do here is throw an error. Is there a
philosophy or policy set forth for PCRE that it matches
on what would be an invalid Perl regex? An error code
should preferably be sent to the caller, and then
handled by the caller.

If for some reason (like backwards compatibility) it is
unacceptable to return an error code for invalid
regexes, then matching on them still does not seem
appropriate. If a regex is wholly and completely
invalid, no matches should be returned for it.

</field>
    <field name="artifact_messages">
<message>
        <field name="adddate">1176824893</field>
        <field name="user_name">nobody</field>
        <field name="body">Logged In: NO 

++ is a &#34;possessive quantifier&#34;, as documented in the pcrepattern man page. First invented in Java, I think, then added to PCRE. It will no longer be incompatible with Perl when Perl 5.10 comes out. (Comment added by PH)</field>
</message>
</field>
    <field name="artifact_history">
<history>
        <field name="field_name">priority</field>
        <field name="old_value">5</field>
        <field name="entrydate">1166050550</field>
        <field name="mod_by">cestith</field>
</history>
</field>
</artifact>
<artifact>
    <field name="artifact_id">1603970</field>
    <field user_id="1655128" name="submitted_by">m_s_m_o</field>
    <field user_id="100" name="assigned_to">nobody</field>
    <field name="priority">5</field>
    <field name="status">Open</field>
    <field name="resolution">None</field>
    <field name="summary">Bug in forward references in backreferences</field>
    <field name="open_date">1164654417</field>
    <field name="artifact_type">Feature Requests</field>
    <field name="category">None</field>
    <field name="artifact_group_id">None</field>
    <field name="details">Forward referencing a backreference (either by name or number) shows inconsistent results on iteration. Here's a PHP example:

-------------------------
1) Forward referencing with + iteration

preg_match( '/(?:\2?(a)(b))+/', 'babbab', $match); print_r($match);

Array
(
    [0] =&#62; abbab
    [1] =&#62; a
    [2] =&#62; b
)


-------------------------
2) Forward referencing with * iteration (Changed + to *)

preg_match( '/(?:\2?(a)(b))*/', 'babbab', $match); print_r($match);

Array
(
    [0] =&#62; 
)


-------------------------
3) Forward referencing with * iteration acts like it was anchored (Removing the &#34;b&#34; from start of subject)


preg_match( '/(?:\2?(a)(b))*/', 'abbab', $match); print_r($match);

Array
(
    [0] =&#62; abbab
    [1] =&#62; a
    [2] =&#62; b
)




Forward references like these seem to be allowed for (?P=name) and \N (where N&#60;=9), showing an error on the second example. However, with N &#62;= 10 it's interpreted as octal unless the Nth group has been opened before referencing.




-------------------------
4) Using \10 before opening the 10th subgroup.

preg_match( '/(?:\10?(a)()()()()()()()()(b))+/', 'abbab', $match); print_r($match);

Array
(
    [0] =&#62; ab
    [1] =&#62; a
    [2] =&#62; 
     .
     .
    [9] =&#62; 
    [10] =&#62; b
)


-------------------------
5) Using \10 before opening the 10th subgroup (Matches the octal).

preg_match( '/(?:\10?(a)()()()()()()()()(b))+/', &#34;ab\10ab&#34;, $match); print_r($match);

Array
(
    [0] =&#62; ab&#194;&#176;ab        &#194;&#176; == chr(8)
    [1] =&#62; a
     .
     .
    [10] =&#62; b
)


-------------------------
6) Using \10 after opening the 10th subgroup (Forward references).

preg_match( '/(?:()()()()()()()()()(\10?a)(b))+/', 'aaabaabaaab', $match); print_r($match);

Array
(
    [0] =&#62; abaabaaab
     .
     .
    [10] =&#62; aaa
    [11] =&#62; b
)</field>
    <field name="artifact_messages">
<message>
        <field name="adddate">1176819052</field>
        <field name="user_name">nobody</field>
        <field name="body">Logged In: NO 

I have only taken a quick look at #1 and #2. There is no error. PCRE, like Perl, finds the first leftmost match. In #2 it can match right at the start, by matching zero times, so it does. In #1 it has to match at least one character, so it can't match at the start, but has to move on to the second character. This is nothing to do with references. (Comment by PH)</field>
</message>

<message>
        <field name="adddate">1164702421</field>
        <field name="user_name">m_s_m_o</field>
        <field name="body">Logged In: YES 
user_id=1655128
Originator: YES

***I forgot the last example: 

7) \10 with * iteration (the one showing the error):

preg_match( '/(?:()()()()()()()()()(\10?a)(b))*/', 'aaabaabaaab', $match); print_r($match);

Array
(
    [0] =&#62; 
)</field>
</message>
</field>
</artifact>
<artifact>
    <field name="artifact_id">1585962</field>
    <field user_id="329603" name="submitted_by">turacma</field>
    <field user_id="100" name="assigned_to">nobody</field>
    <field name="priority">5</field>
    <field name="status">Open</field>
    <field name="resolution">None</field>
    <field name="summary">internal_dfa_exec makes ucp calls outside of #ifdef blocks</field>
    <field name="open_date">1161977811</field>
    <field name="artifact_type">Feature Requests</field>
    <field name="category">None</field>
    <field name="artifact_group_id">None</field>
    <field name="details">The function &#34;internal_dfa_exec&#34; in &#34;pcre_dfa_exec.c&#34;
has many calls to the function &#34;_pcre_ucp_findprop&#34;
that are wrapped within &#34;#ifdef SUPPORT_UCP&#34; blocks,
but has at least five instances that are not wrapped in
these same #ifdef blocks.</field>
    <field name="artifact_messages">
<message>
        <field name="adddate">1176820595</field>
        <field name="user_name">nobody</field>
        <field name="body">Logged In: NO 

That is untidy, but would cause no harm, as the code could never be obeyed. I have tidied it up for the next release. (Comment by PH)</field>
</message>
</field>
</artifact>
<artifact>
    <field name="artifact_id">1550673</field>
    <field user_id="1113403" name="submitted_by">deckrider</field>
    <field user_id="100" name="assigned_to">nobody</field>
    <field name="priority">5</field>
    <field name="status">Open</field>
    <field name="resolution">None</field>
    <field name="summary">patch to 6.6 for hpux ia64 compiler warnings</field>
    <field name="open_date">1157132836</field>
    <field name="artifact_type">Feature Requests</field>
    <field name="category">None</field>
    <field name="artifact_group_id">None</field>
    <field name="details">$ uname -a
HP-UX omztdv2 B.11.23 U ia64 2505142627 unlimited-user
license

$ cc -V
cc: HP aC++/ANSI C B3910B A.06.10 [Mar 22 2006]

The following patch eliminated compiler warnings
produced by using &#34;cc +DD64&#34; (64-bit compile).</field>
    <field name="artifact_messages">
<message>
        <field name="adddate">1176822478</field>
        <field name="user_name">nobody</field>
        <field name="body">Logged In: NO 

Thanks. Noted for the next release. (Comment from PH)</field>
</message>
</field>
    <field name="artifact_history">
<history>
        <field name="field_name">File Added</field>
        <field name="old_value">191622: pcre-6.6-patch.txt</field>
        <field name="entrydate">1157132836</field>
        <field name="mod_by">deckrider</field>
</history>
</field>
</artifact>
<artifact>
    <field name="artifact_id">991074</field>
    <field user_id="100" name="submitted_by">nobody</field>
    <field user_id="100" name="assigned_to">nobody</field>
    <field name="priority">5</field>
    <field name="status">Open</field>
    <field name="resolution">None</field>
    <field name="summary">Typo in pcreapi manpage for named substring matches</field>
    <field name="open_date">1089829211</field>
    <field name="artifact_type">Feature Requests</field>
    <field name="category">None</field>
    <field name="artifact_group_id">None</field>
    <field name="details">Toward the end, the &#34;pcreapi&#34; manpage discusses
extraction of named substring matches.  

The manpage mentions this syntax for naming a substring
match:

     ab(?&#60;xxx&#62;\d+)

but using that yields a runtime error when compiling
the regexp:

     Failed: unrecognized character after (?&#60; at offset 5


Named substring matches require a &#34;P&#34; after the &#34;?&#34;:

     ab(?P&#60;xxx&#62;\d+)


This has been successfully tested both in compiled code
and using the &#34;pcreapi&#34; tool.

-QM qm077 -at- BrandXDev -dot- net</field>
</artifact>
<artifact>
    <field name="artifact_id">572447</field>
    <field user_id="132207" name="submitted_by">mandarax-00</field>
    <field user_id="100" name="assigned_to">nobody</field>
    <field name="priority">5</field>
    <field name="status">Open</field>
    <field name="resolution">None</field>
    <field name="summary">Buffer overflow in &#34;large output vector&#34;</field>
    <field name="open_date">1024741453</field>
    <field name="artifact_type">Feature Requests</field>
    <field name="category">None</field>
    <field name="artifact_group_id">None</field>
    <field name="details">Following NON-UNIX-USE instructions I easily compiled
pcre using MPW on MacOS 9.1, it was really easy.

When I ran pcretest I got crashes in testinput2 case, 
in the &#34;large output vector&#34; case. The reason for the
crash is a very vague one, the actuall crash address
could be different and there is no stack trace (because
it is &#34;classic&#34; MacOS, single process space, no memory
protection, no multithreading etc., it may crash
anywhere). I noticed that usually it happened when
function returns using the address from stack - that
remainds me a classical buffer owerflow issue.

The crash seems to disappear if the &#34;data&#34; for this
test case is truncated to less characters but in this
case the data doesn't match the expression.

The &#34;call chain&#34; for the crash - this isn't a stack
trace though, - indicates, that usually the first
function in this chain is &#34;match&#34;, although the
previous function is unavailable.

There could be some MacOS-pecific issues with
statically allocated data so I tried to allocate the
buffer for the test data from the heap instead of
having statically allocated array. It didn't helped
though. 

Thanks anyway.</field>
    <field name="artifact_messages">
<message>
        <field name="adddate">1024859279</field>
        <field name="user_name">mandarax-00</field>
        <field name="body">Logged In: YES 
user_id=132207

Silly me. &#34;match&#34; is a recursive function and may require
huge stack. A realy huge stack: 256K seemed to be not enough
for &#34;large output vector&#34; case in pcretest. Just to make
sure that I have enough stack space I set AppStack parameter
in cfrg 0 resource to 1M and pcretest passed that test
succesfully. Not a nice solution but it doesn't require any
code changes.

</field>
</message>
</field>
    <field name="artifact_history">
<history>
        <field name="field_name">summary</field>
        <field name="old_value">Buffer overflow in &#34;large output vector&#34;</field>
        <field name="entrydate">1024859279</field>
        <field name="mod_by">mandarax-00</field>
</history>
</field>
</artifact>
<artifact>
    <field name="artifact_id">559307</field>
    <field user_id="100" name="submitted_by">nobody</field>
    <field user_id="100" name="assigned_to">nobody</field>
    <field name="priority">5</field>
    <field name="status">Open</field>
    <field name="resolution">None</field>
    <field name="summary">AutoCAD DLL for Contrib</field>
    <field name="open_date">1022091997</field>
    <field name="artifact_type">Feature Requests</field>
    <field name="category">None</field>
    <field name="artifact_group_id">None</field>
    <field name="details">http://xarch.tu-graz.ac.at/autocad/ads/pcre/
Provides AutoLISP calls for AutoCAD 14 - 2002, 
no replace.

BTW: A Corman Common Lisp binding is in 
development. (with replace)
See http://xarch.tu-
graz.ac.at/autocad/lisp/cormanlisp/src/pcre.lisp

Reini Urban
</field>
</artifact>
<artifact>
    <field name="artifact_id">644644</field>
    <field user_id="100" name="submitted_by">nobody</field>
    <field user_id="100" name="assigned_to">nobody</field>
    <field name="priority">5</field>
    <field name="status">Open</field>
    <field name="resolution">None</field>
    <field name="summary">pcre needs more API regex functions</field>
    <field name="open_date">1038392586</field>
    <field name="artifact_type">Feature Requests</field>
    <field name="category">None</field>
    <field name="artifact_group_id">None</field>
    <field name="details">PCRE lacks a pcre_split() and a pcre_replace(), and I'm
sure someone could think of 5 more functions that
should be in this package.</field>
</artifact>
<artifact>
    <field name="artifact_id">1013155</field>
    <field user_id="100" name="submitted_by">nobody</field>
    <field user_id="100" name="assigned_to">nobody</field>
    <field name="priority">5</field>
    <field name="status">Open</field>
    <field name="resolution">None</field>
    <field name="summary">bug report: pcre_exec(): segmentation fault in utf8 mode</field>
    <field name="open_date">1093039477</field>
    <field name="artifact_type">Feature Requests</field>
    <field name="category">None</field>
    <field name="artifact_group_id">None</field>
    <field name="details">[This is a copy of the bug report 
 sent to the author:  Philip Hazel ]

I'd like to report a bug (with fix) in pcre_exec():
(both in version 4.3 and 4.5)

   8240   rc = match(start_match,
match_block.start_code, 2, &#38;match_block, ims,
         NULL,
   8241     match_isgroup);
   8242 
   8243   if (rc == MATCH_NOMATCH)
   8244     {
   8245     start_match++;
   8246 #ifdef SUPPORT_UTF8
   8247     if (match_block.utf8) 
   8248       while((*start_match &#38; 0xc0) == 0x80)
start_match++;
   8249 #endif
   8250     continue;
   8251     }

Line 8248 doesn't check whether start_match &#60;
end_subject so it may
happen that &#34;*start_match&#34; is evaluated when
start_match == subject + length + 1.   This is usually
harmless except
the rare case where subject[0..length-1] happens to be
at the end
of allocated memory, and subject[length + 1] is outside
the process
address space: then segmentation fault occurs!

Here's the patch to fix this bug. It simply adds
the extra &#34;start_match &#60; end_subject&#34; check.
--- pcre.c      2003-12-10 08:45:44.000000000 -0800
+++ pcre.c.fixed        2004-08-20 14:50:02.000000000 -0700
@@ -8245,7 +8245,8 @@
     start_match++;
 #ifdef SUPPORT_UTF8
     if (match_block.utf8)
-      while((*start_match &#38; 0xc0) == 0x80) start_match++;
+      while(start_match &#60; end_subject &#38;&#38;
+            (*start_match &#38; 0xc0) == 0x80) start_match++;
 #endif
     continue;
     }
</field>
</artifact>
<artifact>
    <field name="artifact_id">1027236</field>
    <field user_id="936756" name="submitted_by">mzn</field>
    <field user_id="100" name="assigned_to">nobody</field>
    <field name="priority">7</field>
    <field name="status">Open</field>
    <field name="resolution">None</field>
    <field name="summary">Bugs in PCRE with PHP</field>
    <field name="open_date">1095083139</field>
    <field name="artifact_type">Feature Requests</field>
    <field name="category">None</field>
    <field name="artifact_group_id">None</field>
    <field name="details">I'm trying to replace some multiple tags like 
&#60;wsb&#62;&#60;/wsb&#62; and &#60;wsimg&#62; with only one regex. While I 
was using few tags, I saw no problem (what indicates 
that the regex is valid), but when the tags reaches some
unknown limit, the system makes very odd things, like:

- Not parsing correctly the text
- Taking much more time to proccess the script if just 
one small new line is inserted

You can see theese glitches in 3 files I've prepared. All 3 
have similar contents, I just changed one line between 
them.

The Code:
---------------
Variations:
1: http://wstec.net/tmp/php_bug_pcre_02/code_01.txt
2: http://wstec.net/tmp/php_bug_pcre_02/code_02.txt
3: http://wstec.net/tmp/php_bug_pcre_02/code_03.txt

What Happens:
--------------
Attention to the line with the &#60;wsx /&#62;

1: http://wstec.net/tmp/php_bug_pcre_02/code_01.php
- Took more than 1 second to parse the text only 2 times
- Parsed everything as it should be parsed
- Note that there aren't spaces in the text among &#60;!-- 
and --&#62;

2: http://wstec.net/tmp/php_bug_pcre_02/code_02.php
- Took more than 1 second to parse the text only 1 time
- Not everything that should be parsed was
- Note the only difference is the spaces in the text 
among &#60;!-- and --&#62;

3: http://wstec.net/tmp/php_bug_pcre_02/code_03.php
- Took less than 1 second to parse the text the same 2 
times than the firs scipt
- Parsed everything as it should be parsed
- Note that the only difference between the previous 
scripts is that line starting with &#60;wsx /&#62;

I hope you understand the issue, I tried to report it to 
PHP ( http://bugs.php.net/?id=30071 ), but they told me 
to report HERE, so I'm doing it.</field>
    <field name="artifact_history">
<history>
        <field name="field_name">priority</field>
        <field name="old_value">5</field>
        <field name="entrydate">1095083218</field>
        <field name="mod_by">mzn</field>
</history>
</field>
</artifact>
<artifact>
    <field name="artifact_id">1154955</field>
    <field user_id="1230824" name="submitted_by">jpm42</field>
    <field user_id="100" name="assigned_to">nobody</field>
    <field name="priority">5</field>
    <field name="status">Open</field>
    <field name="resolution">None</field>
    <field name="summary">(A)* crashes pcretest.exe</field>
    <field name="open_date">1109757592</field>
    <field name="artifact_type">Feature Requests</field>
    <field name="category">None</field>
    <field name="artifact_group_id">None</field>
    <field name="details">pattern: (A*)
data: 3KB file of A's
--&#62; everything works as expected with testpcre.exe

pattern: (A)*
data: 3KB file of A's
--&#62; pcretest.exe crashes
if the size of data is less than 1092Bytes or so the 
crash doesn't occur

the crash occurs inside the pcre_exec() function at a 
call of match()

system:
window 2000 prof.
pcre version 5.0
VC 6.0


</field>
    <field name="artifact_history">
<history>
        <field name="field_name">File Added</field>
        <field name="old_value">123815: pcretest.txt</field>
        <field name="entrydate">1109757593</field>
        <field name="mod_by">jpm42</field>
</history>
</field>
</artifact>
<artifact>
    <field name="artifact_id">1209493</field>
    <field user_id="803149" name="submitted_by">loufoque</field>
    <field user_id="100" name="assigned_to">nobody</field>
    <field name="priority">5</field>
    <field name="status">Open</field>
    <field name="resolution">None</field>
    <field name="summary">full regular expression support inside lookbehind</field>
    <field name="open_date">1117144772</field>
    <field name="artifact_type">Feature Requests</field>
    <field name="category">None</field>
    <field name="artifact_group_id">None</field>
    <field name="details">It would be great if PCRE supported the use full
regular expressions inside lookbehind like PowerGREP
and the .NET framework do.
As of now, only fixed-length strings are allowed.</field>
</artifact>
<artifact>
    <field name="artifact_id">1230856</field>
    <field user_id="1196905" name="submitted_by">evseev</field>
    <field user_id="100" name="assigned_to">nobody</field>
    <field name="priority">5</field>
    <field name="status">Open</field>
    <field name="resolution">None</field>
    <field name="summary">Missing manual pages</field>
    <field name="open_date">1120214497</field>
    <field name="artifact_type">Feature Requests</field>
    <field name="category">None</field>
    <field name="artifact_group_id">None</field>
    <field name="details">This is very old bug initially fixed in DEbian and taken to 
ALTLinux build since 4.4-alt1 on Nov 2003: there is no 
manual page for pcre-config utility. Here is a patch.</field>
    <field name="artifact_messages">
<message>
        <field name="adddate">1176887660</field>
        <field name="user_name">nobody</field>
        <field name="body">Logged In: NO 

Now that somebody has finally brought this to my attention, I have added the man page to the distribution for the 7.1 release. (Comment by PH)</field>
</message>
</field>
    <field name="artifact_history">
<history>
        <field name="field_name">File Added</field>
        <field name="old_value">140478: pcre-6.0-alt-missingman.tar.bz2</field>
        <field name="entrydate">1120214497</field>
        <field name="mod_by">evseev</field>
</history>
</field>
</artifact>
<artifact>
    <field name="artifact_id">1230863</field>
    <field user_id="1196905" name="submitted_by">evseev</field>
    <field user_id="100" name="assigned_to">nobody</field>
    <field name="priority">5</field>
    <field name="status">Open</field>
    <field name="resolution">None</field>
    <field name="summary">&#34;make check&#34; failed because missing dependencies</field>
    <field name="open_date">1120214946</field>
    <field name="artifact_type">Feature Requests</field>
    <field name="category">None</field>
    <field name="artifact_group_id">None</field>
    <field name="details">C++ test suite (see CPP_TARGET macro in Makefile) is 
not compiled under 'all' nor 'test' targets. So 'make 
check' is failed because there are no suitable binaries to 
exec.</field>
    <field name="artifact_history">
<history>
        <field name="field_name">File Added</field>
        <field name="old_value">140483: pcre-6.0-alt-cpptests.patch</field>
        <field name="entrydate">1120214946</field>
        <field name="mod_by">evseev</field>
</history>
</field>
</artifact>
<artifact>
    <field name="artifact_id">1263540</field>
    <field user_id="785019" name="submitted_by">hilfingr</field>
    <field user_id="100" name="assigned_to">nobody</field>
    <field name="priority">5</field>
    <field name="status">Open</field>
    <field name="resolution">None</field>
    <field name="summary">Better support for separate build/source directories</field>
    <field name="open_date">1124404096</field>
    <field name="artifact_type">Feature Requests</field>
    <field name="category">None</field>
    <field name="artifact_group_id">None</field>
    <field name="details">Currently, building PCRE in a directory different from the 
source directory does not work terribly well (PCRE v 6.1,
built on Solaris 8).  The attached patch worked for me.



</field>
    <field name="artifact_messages">
<message>
        <field name="adddate">1176825549</field>
        <field name="user_name">nobody</field>
        <field name="body">Logged In: NO 

PCRE 7.1 (out soon) will use a &#34;standard&#34; Autotools way of building. Hopefully this will solve the problem. (Comment from PH)</field>
</message>
</field>
    <field name="artifact_history">
<history>
        <field name="field_name">File Added</field>
        <field name="old_value">146182: pcre-diffs</field>
        <field name="entrydate">1124404097</field>
        <field name="mod_by">hilfingr</field>
</history>
</field>
</artifact>
<artifact>
    <field name="artifact_id">1273897</field>
    <field user_id="100" name="submitted_by">nobody</field>
    <field user_id="100" name="assigned_to">nobody</field>
    <field name="priority">5</field>
    <field name="status">Open</field>
    <field name="resolution">None</field>
    <field name="summary">Continuous search support</field>
    <field name="open_date">1125049966</field>
    <field name="artifact_type">Feature Requests</field>
    <field name="category">None</field>
    <field name="artifact_group_id">None</field>
    <field name="details">Dear developers:

Could we support the continuous search?
I mean search one buffer and keep the 
temporal search state if the search match
no thing. And re-use the  search state to search 
the next buffer.
This feature will be useful when search the
network packet , because it is not the continuous
buffer. 

Sincerely,
Larry
</field>
</artifact>
<artifact>
    <field name="artifact_id">1273898</field>
    <field user_id="100" name="submitted_by">nobody</field>
    <field user_id="100" name="assigned_to">nobody</field>
    <field name="priority">5</field>
    <field name="status">Open</field>
    <field name="resolution">None</field>
    <field name="summary">Continuous search support</field>
    <field name="open_date">1125049968</field>
    <field name="artifact_type">Feature Requests</field>
    <field name="category">None</field>
    <field name="artifact_group_id">None</field>
    <field name="details">Dear developers:

Could we support the continuous search?
I mean search one buffer and keep the 
temporal search state if the search match
no thing. And re-use the  search state to search 
the next buffer.
This feature will be useful when search the
network packet , because it is not the continuous
buffer. 

Sincerely,
Larry
</field>
</artifact>
<artifact>
    <field name="artifact_id">1290152</field>
    <field user_id="560431" name="submitted_by">goo0h</field>
    <field user_id="100" name="assigned_to">nobody</field>
    <field name="priority">5</field>
    <field name="status">Open</field>
    <field name="resolution">None</field>
    <field name="summary">Install of 6.4 now causes problems</field>
    <field name="open_date">1126626939</field>
    <field name="artifact_type">Feature Requests</field>
    <field name="category">None</field>
    <field name="artifact_group_id">None</field>
    <field name="details">For many years now we have installed apps in
directories other than where the files will reside on
production systems. We then use a tool (depot from CMU
as it happens) to map these files into the production
area. Since the compiled paths are intact and correct
after such linking, everything works as expected. If we
were to set install prefix to be where the files will
be installed into, then that directory location has to
either always be mounted, or the files have to be
installed out into this area on client machines. The
latter could probably be done, but with quite a bit of
effort.

This is the result I got when attempting to install the
latest version. This was never an issue in the past.

/bin/bash ./libtool --mode=install /usr/ucb/install
libpcreposix.la
/usr/soft/that/pcre-6.4/run/default/sparc_sun_solaris2.8/lib/libpcreposix.lalibtool:
install: error: cannot install `libpcreposix.la' to a
directory not ending in /usr/local/lib
gmake: *** [install] Error 1

And I see why this is happening:

          # Don't allow the user to place us outside of
our expected
          # location b/c this prevents finding
dependent libraries that
          # are installed to the same prefix.
          # At present, this check doesn't affect
windows .dll's that
          # are installed into $libdir/../bin
(currently, that works fine)
          # but it's something to keep an eye on.
          if test &#34;$inst_prefix_dir&#34; = &#34;$destdir&#34;; then
            $echo &#34;$modename: error: cannot install
\`$file' to a directory not ending in $libdir&#34; 1&#62;&#38;2
            exit $EXIT_FAILURE
          fi

I can understand why this was done, but unfortunately
it breaks what we've been (successfully) doing for many
years now. Any recommendations on how to proceed? If
all GNU software is going to start doing this, man
we're going to have a hell of a time.

</field>
</artifact>
<artifact>
    <field name="artifact_id">1345336</field>
    <field user_id="1156714" name="submitted_by">wyrmok</field>
    <field user_id="100" name="assigned_to">nobody</field>
    <field name="priority">5</field>
    <field name="status">Open</field>
    <field name="resolution">None</field>
    <field name="summary">BUG: core dump on 64-bit platform</field>
    <field name="open_date">1130882470</field>
    <field name="artifact_type">Feature Requests</field>
    <field name="category">None</field>
    <field name="artifact_group_id">None</field>
    <field name="details">When I do 'make test', I get a core dump inside
pcre_fullinfo simply because of the following

  case PCRE_INFO_OPTIONS:
  *((unsigned long int *)where) = re-&#62;options &#38;
PUBLIC_OPTIONS;
  break;

where is actually a pointer to a 32 bit integer and
unsigned long int is 64 bit. When I change the cast to
(int *), 'make test' ends up with many errors without
core dump.

I download 6.3 today. This problem is found on solaris
8 using gcc 3.4 and SunCC.

</field>
    <field name="artifact_messages">
<message>
        <field name="adddate">1176825199</field>
        <field name="user_name">nobody</field>
        <field name="body">Logged In: NO 

It is documented that &#34;where&#34; must point to an unsigned long int variable. (Comment from PH)</field>
</message>
</field>
</artifact>
<artifact>
    <field name="artifact_id">1409517</field>
    <field user_id="167561" name="submitted_by">efalk</field>
    <field user_id="100" name="assigned_to">nobody</field>
    <field name="priority">5</field>
    <field name="status">Open</field>
    <field name="resolution">None</field>
    <field name="summary">rpm spec file</field>
    <field name="open_date">1137628121</field>
    <field name="artifact_type">Feature Requests</field>
    <field name="category">None</field>
    <field name="artifact_group_id">None</field>
    <field name="details">Howdy; just thought I'd contribute a .spec file that
works with pcre-6.3 under Redhat9.  I expect it will
work on Fedora as well.

You'll want to tweak it just a bit (subsititute your
name for mine, etc.) and possibly move it to
pcre.spec.in and teach automake to add the version &#38;
release info.

Also, I have .rpm files I built with it under RH9 if
you'd like to place them in your file release area.

  -ed falk</field>
    <field name="artifact_history">
<history>
        <field name="field_name">File Added</field>
        <field name="old_value">163960: pcre.spec</field>
        <field name="entrydate">1137628122</field>
        <field name="mod_by">efalk</field>
</history>
</field>
</artifact>
<artifact>
    <field name="artifact_id">1535057</field>
    <field user_id="100" name="submitted_by">nobody</field>
    <field user_id="100" name="assigned_to">nobody</field>
    <field name="priority">5</field>
    <field name="status">Open</field>
    <field name="resolution">None</field>
    <field name="summary">/usr/bin/ld: Undefined symbols</field>
    <field name="open_date">1154788386</field>
    <field name="artifact_type">Feature Requests</field>
    <field name="category">None</field>
    <field name="artifact_group_id">None</field>
    <field name="details">Whenever I try to compile a simple C++ code containing
PCRE, I get an error to do with ld. 

/usr/bin/ld: Undefined symbols:
pcrecpp::RE::Init(char const*, pcrecpp::RE_Options const*)
pcrecpp::RE::~RE()
collect2: ld returned 1 exit status

And here is the code:

#include &#60;pcrecpp.h&#62;

int main ( )
{
    pcrecpp::RE re(&#34;h.*o&#34;);
}

Any help would be great. Contact me at acoolie@???</field>
</artifact>
<artifact>
    <field name="artifact_id">1423897</field>
    <field user_id="716975" name="submitted_by">gasp0de</field>
    <field user_id="100" name="assigned_to">nobody</field>
    <field name="priority">5</field>
    <field name="status">Open</field>
    <field name="resolution">None</field>
    <field name="summary">definition missing for PCRE_DATA_SCOPE in pcreposix.h</field>
    <field name="open_date">1139028478</field>
    <field name="artifact_type">Feature Requests</field>
    <field name="category">None</field>
    <field name="artifact_group_id">None</field>
    <field name="details">For version 6.5, ChangeLog, number 16: 
    (a) pcreposix.h still had just &#34;extern&#34; instead 
of either of these macros; 
        I have replaced it with PCRE_DATA_SCOPE. 
 
Just mentioning that you forgot to define 
PCRE_DATA_SCOPE. 
 
//Gasp0dE </field>
    <field name="artifact_messages">
<message>
        <field name="adddate">1139280144</field>
        <field name="user_name">nobody</field>
        <field name="body">Logged In: NO 

This has been fixed in version 6.6.</field>
</message>
</field>
</artifact>
<artifact>
    <field name="artifact_id">1467534</field>
    <field user_id="100" name="submitted_by">nobody</field>
    <field user_id="100" name="assigned_to">nobody</field>
    <field name="priority">5</field>
    <field name="status">Open</field>
    <field name="resolution">None</field>
    <field name="summary">\A doesn't respect the REG_NOTBOL flag</field>
    <field name="open_date">1144648161</field>
    <field name="artifact_type">Feature Requests</field>
    <field name="category">None</field>
    <field name="artifact_group_id">None</field>
    <field name="details">I would expect \A to act the same as ^ when REG_NOTBOL
is used, but it doesn't.</field>
    <field name="artifact_messages">
<message>
        <field name="adddate">1176822828</field>
        <field name="user_name">nobody</field>
        <field name="body">Logged In: NO 

This behaviour is documented: &#34;The \A, \Z, and \z assertions differ from the traditional circumflex and dollar (described in the next section) in that they only ever match at the very start and end of the subject string, whatever options are set. Thus, they are independent of multiline mode. These three assertions are not affected by the PCRE_NOTBOL or PCRE_NOTEOL options, which affect only the behaviour of the circumflex and dollar metacharacters.&#34; (Comment by PH)</field>
</message>
</field>
</artifact>
<artifact>
    <field name="artifact_id">1446989</field>
    <field user_id="100" name="submitted_by">nobody</field>
    <field user_id="100" name="assigned_to">nobody</field>
    <field name="priority">5</field>
    <field name="status">Open</field>
    <field name="resolution">None</field>
    <field name="summary">bug in evaluation regular expresion</field>
    <field name="open_date">1141971279</field>
    <field name="artifact_type">Feature Requests</field>
    <field name="category">None</field>
    <field name="artifact_group_id">None</field>
    <field name="details">I encounter this bug in PHP, so I posted this bug in 
PHP bug list, but I was redirected here because this 
is &#34;libpcre bug&#34;.

It seems like bug in evaluation regular expresion. See 
code.

Reproduce code:
---------------
/* 1. this produces warning : Compilation failed: 
lookbehind assertion is not fixed length ... */
 if (preg_match(&#34;/(?&#60;![^f]oo)(bar)/i&#34;, &#34;xoobar&#34;)&#62;0) 
echo &#34;Match3&#34;;

/* 2. this does not produces warning */
 if (preg_match(&#34;/(?&#60;![^fo]o)(bar)/i&#34;, &#34;xoobar&#34;)&#62;0) 
echo &#34;Match4&#34;;

Expected result:
----------------
Case 1 without warning
Case 2 without warning


Actual result:
--------------
Case 1 with warning &#34;Compilation failed: lookbehind 
assertion is not fixed length ...&#34;
Case 2 without warning</field>
    <field name="artifact_messages">
<message>
        <field name="adddate">1176823056</field>
        <field name="user_name">nobody</field>
        <field name="body">Logged In: NO 

This was fixed in PCRE 6.7. (Comment from PH)</field>
</message>
</field>
</artifact>
<artifact>
    <field name="artifact_id">1466977</field>
    <field user_id="1497678" name="submitted_by">therealcrisp</field>
    <field user_id="100" name="assigned_to">nobody</field>
    <field name="priority">5</field>
    <field name="status">Open</field>
    <field name="resolution">None</field>
    <field name="summary">Prevent backtracking for trivial cases</field>
    <field name="open_date">1144526892</field>
    <field name="artifact_type">Feature Requests</field>
    <field name="category">None</field>
    <field name="artifact_group_id">None</field>
    <field name="details">Some example using PCRE 6.6:

  re&#62; /([a-y]+|z)+#/gD
------------------------------------------------------------------
  0  50 Bra 0
  3  37 Bra 1
  6     [a-y]+
 40   5 Alt
 43     z
 45  42 KetRmax
 48     #
 50  50 Ket
 53     End
------------------------------------------------------------------
Capturing subpattern count = 1
Partial matching not supported
No options
No first char
Need char = '#'
data&#62; foo# bar# abcdefghijklmnopqrst bla#
 0: foo#
 1: foo
 0: bar#
 1: bar
 0: bla#
 1: bla
data&#62; foo# bar# abcdefghijklmnopqrstu bla#
 0: foo#
 1: foo
 0: bar#
 1: bar
Error -8


As you can see the backtracking and the amount of
variations that are being tried eventually results in
PCRE_ERROR_MATCHLIMIT being raised.
In my opinion this should not be necessary if at first
a selection is made to determine which execution-paths
will lead to nowhere instead of just trying them all.
Such decision could be made if it becomes obvious that
there's a big chance we need to do some heavy
backtracking. The cost to exclude certain posibilities
imho outweighs the penalty of the backtracking or even
- as in this case - failure to complete the matching.</field>
</artifact>
<artifact>
    <field name="artifact_id">1470407</field>
    <field user_id="100" name="submitted_by">nobody</field>
    <field user_id="100" name="assigned_to">nobody</field>
    <field name="priority">5</field>
    <field name="status">Open</field>
    <field name="resolution">None</field>
    <field name="summary">make fails on AIX 5.3</field>
    <field name="open_date">1145027418</field>
    <field name="artifact_type">Feature Requests</field>
    <field name="category">None</field>
    <field name="artifact_group_id">None</field>
    <field name="details">tdyboc@???

Strange.  Running make or make all fails.

If I run individually they work but I don't know if 
anything is truly missing.  Looks fine.
     make libpcre.la
     make libpcreposix.la
     make prcetest
     make pcregrep

Error from make or make all:

creating pcregrep
 g++ -c -g -O2 -I. -I. -
DPOSIX_MALLOC_THRESHOLD=10 ./pcrecpp.cc  -DPIC -
o .libs/pcrecpp.o
 g++ -c -g -O2 -I. -I. -
DPOSIX_MALLOC_THRESHOLD=10 ./pcre_scanner.cc  -DPIC -
o .libs/pcre_scanner.o
 g++ -c -g -O2 -I. -I. -
DPOSIX_MALLOC_THRESHOLD=10 ./pcre_stringpiece.cc  -
DPIC -o .libs/pcre_stringpiece.o
        rm -f libpcrecpp.la
        /bin/sh ./libtool --mode=link g++  -I. -I. -
rpath /usr/local/lib libpcre.la -version-
info  '0:0:0' -o libpcrecpp.la pcrecpp.lo  
pcre_scanner.lo  pcre_stringpiece.lo
generating symbol list for `libpcrecpp.la'
/usr/bin/nm -B -
BCpg  .libs/pcrecpp.o .libs/pcre_scanner.o .libs/pcre_s
tringpiece.o  | awk '{ if ((($2 == &#34;T&#34;) || ($2 == &#34;D&#34;)

|| ($2 == "B")) && (substr($3,1,1) != ".")) { print

$3 } }' | sort -u &#62; .libs/libpcrecpp.exp
g++ -shared -
o .libs/libpcrecpp.so.0  .libs/pcrecpp.o .libs/pcre_sca
nner.o .libs/pcre_stringpiece.o  -Wl,-
blibpath:/gpfs/dba/utilities/pcre-
6.6/.libs:/usr/local/lib/.:/usr/local/lib:/usr/local/li
b/gcc-lib/powerpc-ibm-
aix5.2.0.0/3.3.2:/usr/local/lib/gcc-lib/powerpc-ibm-
aix5.2.0.0/3.3.2/../../..:/usr/lib:/lib -L./.libs -
lpcre -L/usr/local/lib/gcc-lib/powerpc-ibm-
aix5.2.0.0/3.3.2 -L/usr/local/lib/gcc-lib/powerpc-ibm-
aix5.2.0.0/3.3.2/../../.. -L/usr/local/lib/. -lstdc++ -
L/internet/po/gcc-3.3.2-obj/powerpc-ibm-
aix5.2.0.0/libstdc++-v3/src -L/internet/po/gcc-3.3.2-
obj/powerpc-ibm-aix5.2.0.0/libstdc++-v3/src/.libs -
L/internet/po/gcc-3.3.2-obj/gcc -L/usr/local/lib -lm -
lc -lgcc_s -Wl,-bnoentry  -Wl,-bE:.libs/libpcrecpp.exp 
${wl}-berok
ld: 0711-415 WARNING: Symbol 
_GLOBAL__I__ZN7pcrecpp6no_argE is already exported.
ld: 0711-415 WARNING: Symbol 
_GLOBAL__D__ZN7pcrecpp6no_argE is already exported.
ld: 0711-415 WARNING: Symbol 
_GLOBAL__F__ZN7pcrecpp6no_argE is already exported.
ld: 0711-415 WARNING: Symbol 
_GLOBAL__F__ZN7pcrecpp7ScannerC2Ev is already exported.
ld: 0711-415 WARNING: Symbol 
_GLOBAL__I__ZlsRSoRKN7pcrecpp11StringPieceE is already 
exported.
ld: 0711-415 WARNING: Symbol 
_GLOBAL__D__ZlsRSoRKN7pcrecpp11StringPieceE is already 
exported.
ld: 0711-415 WARNING: Symbol 
_GLOBAL__F__ZlsRSoRKN7pcrecpp11StringPieceE is already 
exported.
ld: 0711-999 SEVERE ERROR: Unexpected system call 
error.
        ld:ftruncate() I/O error
ld: 0711-996 Error occurred while processing 
file: .libs/libpcrecpp.so.0
collect2: ld returned 12 exit status
make: 1254-004 The error code from the last command is 
1.

</field>
</artifact>
<artifact>
    <field name="artifact_id">1523285</field>
    <field user_id="100" name="submitted_by">nobody</field>
    <field user_id="100" name="assigned_to">nobody</field>
    <field name="priority">5</field>
    <field name="status">Open</field>
    <field name="resolution">None</field>
    <field name="summary">Mac OSX &#38; snort pcre - bus error  - [^a] bug?</field>
    <field name="open_date">1153030544</field>
    <field name="artifact_type">Feature Requests</field>
    <field name="category">None</field>
    <field name="artifact_group_id">None</field>
    <field name="details">The below regexes kill snort with a bus error. I
believe this is a Mac OSX specific error.

I have tested them via pcretest and can confirm same
happens outside of snort with the pcretest application.


/^SSH-\s[^\n]{200}/ism
/^CSeq\x3A\s*[^\nA-Za-z]*[A-Za-z][^\n]{16,}/smi
/\x2fnds\x2f[^&#38;\r\n\x3b]{500}/smi


computer:~/Desktop/pcre-6.3 Nicholas$ ./pcretest 
PCRE version 6.3 15-Aug-2005

  re&#62; /^CSeq\x3A\s*[^\nA-Za-z]*[A-Za-z][^\n]{16,}/smi
Bus error


computer:~/Desktop/pcre-6.3 user$ ./pcretest 
PCRE version 6.3 15-Aug-2005

  re&#62; /\x2fnds\x2f[^&#38;\r\n\x3b]{500}/smi
Bus error


a more simplistic version:

computer:~/Desktop/pcre-6.3 user$ ./pcretest 
PCRE version 6.3 15-Aug-2005

  re&#62; /abc[^d]/
Bus error


Something to do with the NOT 'd' ???

Thanks

Mohclips.</field>
    <field name="artifact_messages">
<message>
        <field name="adddate">1153071062</field>
        <field name="user_name">nobody</field>
        <field name="body">Logged In: NO 

forget it, i found a newer version here that works;

ftp://ftp.csx.cam.ac.uk/pub/software/programming/pcre/pcre-6.6.tar.gz

Mohclips.</field>
</message>
</field>
</artifact>
<artifact>
    <field name="artifact_id">1536273</field>
    <field user_id="512388" name="submitted_by">pierre42</field>
    <field user_id="100" name="assigned_to">nobody</field>
    <field name="priority">5</field>
    <field name="status">Open</field>
    <field name="resolution">None</field>
    <field name="summary">Errors testing pcre 6.7</field>
    <field name="open_date">1154981652</field>
    <field name="artifact_type">Feature Requests</field>
    <field name="category">None</field>
    <field name="artifact_group_id">None</field>
    <field name="details"># make check
PCRE version 6.7 04-Jul-2006

Test 1: main functionality (Perl compatible)
23c23
&#60; No match
---
&#62;  0: abcd\x09\x0a\x0d\x0c\x07\x1b9;$\?caxyz
27c27
&#60; No match
---
&#62;  0: abxyzpqrrrabbxyyyypqAzz
29c29
&#60; No match
---
&#62;  0: abxyzpqrrrabbxyyyypqAzz
31c31
&#60; No match
---
&#62;  0: aabxyzpqrrrabbxyyyypqAzz
33c33
&#60; No match
---
&#62;  0: aaabxyzpqrrrabbxyyyypqAzz
35c35
&#60; No match
---
&#62;  0: aaaabxyzpqrrrabbxyyyypqAzz
37c37
&#60; No match
---
&#62;  0: abcxyzpqrrrabbxyyyypqAzz
39c39
&#60; No match
---
&#62;  0: aabcxyzpqrrrabbxyyyypqAzz
41c41
&#60; No match
---
&#62;  0: aaabcxyzpqrrrabbxyyyypAzz
43c43
&#60; No match
---
&#62;  0: aaabcxyzpqrrrabbxyyyypqAzz
45c45
&#60; No match
---
&#62;  0: aaabcxyzpqrrrabbxyyyypqqAzz
47c47
&#60; No match
---
&#62;  0: aaabcxyzpqrrrabbxyyyypqqqAzz
49c49
&#60; No match
---
&#62;  0: aaabcxyzpqrrrabbxyyyypqqqqAzz
51c51
&#60; No match
---
&#62;  0: aaabcxyzpqrrrabbxyyyypqqqqqAzz
53c53
&#60; No match
---
&#62;  0: aaabcxyzpqrrrabbxyyyypqqqqqqAzz
55c55
&#60; No match
---
&#62;  0: aaaabcxyzpqrrrabbxyyyypqAzz
57c57
&#60; No match
---
&#62;  0: abxyzzpqrrrabbxyyyypqAzz
59c59
&#60; No match
---
&#62;  0: aabxyzzzpqrrrabbxyyyypqAzz
61c61
&#60; No match
---
&#62;  0: aaabxyzzzzpqrrrabbxyyyypqAzz
63c63
&#60; No match
---
&#62;  0: aaaabxyzzzzpqrrrabbxyyyypqAzz
65c65
&#60; No match
---
&#62;  0: abcxyzzpqrrrabbxyyyypqAzz
67c67
&#60; No match
---
&#62;  0: aabcxyzzzpqrrrabbxyyyypqAzz
69c69
&#60; No match
---
&#62;  0: aaabcxyzzzzpqrrrabbxyyyypqAzz
71c71
&#60; No match
---
&#62;  0: aaaabcxyzzzzpqrrrabbxyyyypqAzz
73c73
&#60; No match
---
&#62;  0: aaaabcxyzzzzpqrrrabbbxyyyypqAzz
75c75
&#60; No match
---
&#62;  0: aaaabcxyzzzzpqrrrabbbxyyyyypqAzz
77c77
&#60; No match
---
&#62;  0: aaabcxyzpqrrrabbxyyyypABzz
79c79
&#60; No match
---
&#62;  0: aaabcxyzpqrrrabbxyyyypABBzz
81c81
&#60; No match
---
&#62;  0: aaabxyzpqrrrabbxyyyypqAzz
83c83
&#60; No match
---
[...]


and so on...</field>
</artifact>
</artifacts>

<tasks>

</tasks>

<documents>

</documents>

<news>

</news>

</project_export>

Aquest missatge és part del següent fil:
	l'arbre de fils complet ordenat per data
	Andrew Ho en
	Magnus Holmgren en