php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Bug #77388 invalid range in character class doesn't bubble up
Submitted: 2018-12-31 11:22 UTC Modified: 2021-07-09 16:28 UTC
Votes:1
Avg. Score:5.0 ± 0.0
Reproduced:1 of 1 (100.0%)
Same Version:1 (100.0%)
Same OS:1 (100.0%)
From: sjon at hortensius dot net Assigned: cmb (profile)
Status: Closed Package: PCRE related
PHP Version: 7.3.0 OS: archlinux
Private report: No CVE-ID: None
View Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
If you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: sjon at hortensius dot net
New email:
PHP Version: OS:

 

 [2018-12-31 11:22 UTC] sjon at hortensius dot net 
Description:
------------
I found this while going through https://3v4l.org/bughunt/7.3.0/7.2.13+7.2.12 I'm  not sure if this is a PHP or a PCRE bug (or maybe not a bug at all) but running the same regexp through pcre2test yields an error - but php accepts it since 7.3

$ pcre2test 
PCRE2 version 10.32 2018-09-10
  re> /[^_-\s]/
Failed: error 150 at offset 6: invalid range in character class


Test script:
---------------
See https://3v4l.org/KICjT

var_dump(preg_replace( '/[^_-\s]/' , '' , 'a b c d _ x' ));

Expected result:
----------------
Warning: preg_replace(): Compilation failed: invalid range in character class at offset 5 in /in/KICjT on line 3

Actual result:
--------------
string(5) "abcd_"

Patches

Pull Requests

Pull requests:

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2018-12-31 11:35 UTC] nikic@php.net 
Might be because we're setting PCRE2_EXTRA_BAD_ESCAPE_IS_LITERAL for BC reasons, though I don't think it's *supposed* to affect this case.
 [2018-12-31 11:41 UTC] nikic@php.net 
Just checked, /[^_-\s]/bad_escape_is_literal in pcre2test works, so this is indeed the reason.

I think this is a PCRE bug though, because I don't think that option should affect this particular case, because \s is a legal escape, it's just not allowed as part of a range. Something like /[^\s-_]/bad_escape_is_literal results in a "Unrecognized escape sequence "\s"" error.
 [2019-01-01 14:58 UTC] sjon at hortensius dot net 
thanks, I agree. I've filed https://bugs.exim.org/show_bug.cgi?id=2362 upstream
 [2019-01-06 10:22 UTC] sjon at hortensius dot net 
this has been fixed in https://vcs.pcre.org/pcre2?view=revision&revision=1058

It's also advisable to stop passing the BAD_ESCAPE_IS_LITERAL flag by default from PHP, should I file a separate bug/feature for that?
 [2019-01-09 19:05 UTC] cmb@php.net 
> It's also advisable to stop passing the BAD_ESCAPE_IS_LITERAL
> flag by default from PHP, […]

Would you mind starting a discussion on the internals@ mailing
list?

> […] , should I file a separate bug/feature for that?

IMHO, this ticket is fine.
 [2019-07-17 09:15 UTC] sjon@php.net 
The following pull request has been associated:

Patch Name: Ref #77388 - disallow passing BAD_ESCAPE_IS_LITERAL, esp by default
On GitHub:  https://github.com/php/php-src/pull/4429
Patch:      https://github.com/php/php-src/pull/4429.patch
 [2019-07-17 10:26 UTC] sjon@php.net 
The following pull request has been associated:

Patch Name: Ref #77388 - disallow passing BAD_ESCAPE_IS_LITERAL, esp by default
On GitHub:  https://github.com/php/php-src/pull/4430
Patch:      https://github.com/php/php-src/pull/4430.patch
 [2021-07-09 16:28 UTC] cmb@php.net
-Status: Open +Status: Closed -Assigned To: +Assigned To: cmb
 [2021-07-09 16:28 UTC] cmb@php.net 
PR #4430 has been merged long ago.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved. 		Last updated: Wed Nov 27 23:01:27 2024 UTC