------- You are receiving this mail because: -------
You are on the CC list for the bug.
http://bugs.exim.org/show_bug.cgi?id=1429
--- Comment #2 from Bruno <bruno+pcre@???> 2013-12-31 10:35:38 ---
(In reply to comment #1)
>
> I don't use PHP, but it seems to me that PHP ought to treat a PCRE
> compile-time error more seriously. What does it do with other pattern
> errors, for example /[abc/ (which has a missing ])?
>
> > PS : Today, there is not 8.34 option in the version listbox on this page.
>
> There is now. Sorry about that; it's even on my list of "things you must
> do when making a new release" but somehow I overlooked it.
>
> Philip
>
Thank you and happy new year !
Here is a little test with php :
<?php
$a = preg_replace("/[^._=-\w]+/","_","b'lal.");
echo gettype($a)." $a \n";
$a = preg_replace("/[abc/","_","b'lal.");
echo gettype($a)." $a \n";
?>
And the results when php is linked to libpcre 8.34
PHP Warning: PHP Warning: preg_replace(): Compilation failed: invalid range in
character class at offset 7 in - on line 2
NULL
PHP Warning: preg_replace(): Compilation failed: missing terminating ] for
character class at offset 4 in - on line 5
NULL
And the results when php is linked to libpcre 8.33
string b_lal.
PHP Warning: preg_replace(): Compilation failed: missing terminating ] for
character class at offset 4 in - on line 5
NULL
So PHP returns NULL with a warning when there is a compilation error.
But as the bogus expression compiled with older version of libpcre without PHP
warning, such errors exist in php applications :-(
--
Configure bugmail:
http://bugs.exim.org/userprefs.cgi?tab=email
