-
Notifications
You must be signed in to change notification settings - Fork 7.9k
makes mb_ereg
clear the $regs
argument on failure
#2046
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -19,15 +19,16 @@ foreach ($a as $args) { | |
} | ||
?> | ||
===DONE=== | ||
--EXPECTF-- | ||
--EXPECTF-- | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I'd prefer to avoid whitespace changes in bug fixes (and feature implementations, for that matter), because that makes it easier to read the diff. (Yeah, I know that these trailing whitespaces shouldn't be there in the first place, but a separate commit/pull request might be more appropriate to fix this.) There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @cmb69 Ah yeah sorry, this is automatic editor behavior... |
||
bool(false) | ||
array(3) { | ||
[0]=> | ||
int(1) | ||
[1]=> | ||
int(2) | ||
[2]=> | ||
int(3) | ||
array(0) { | ||
} | ||
} | ||
|
||
Warning: mb_ereg(): empty pattern in %s on line %d | ||
|
@@ -38,7 +39,8 @@ array(3) { | |
[1]=> | ||
string(0) "" | ||
[2]=> | ||
string(0) "" | ||
array(0) { | ||
} | ||
} | ||
|
||
Notice: Array to string conversion in %s on line %d | ||
|
@@ -50,7 +52,8 @@ array(3) { | |
[1]=> | ||
int(1) | ||
[2]=> | ||
string(0) "" | ||
array(0) { | ||
} | ||
} | ||
|
||
Warning: mb_ereg() expects parameter 2 to be string, array given in %s on line %d | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
IMO, that change (yield empty array instead of null) makes sense, but I'm not sure whether it should be part of this bug fix. Sticking with the current behavior might avoid BC breaks.
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@cmb69 The function did not yield null, it just didn't modify the
zval
you passed as an argument when the match fails. If it was a string it stays a string, if it was not defined it will be null, etc...This behavior was not consitent with
preg_match
, was highly counter-intuitive and looked like a bug to me:There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
But of course, I can rebase on another branch if it's too much a BC break.
Just tell me.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, now I understand! Thanks.
I agree that the behavior of preg_match() makes more sense, but mb_ereg() behaves like ereg(). Changing the behavior of the former, but not that of the latter, would be inconsistent. However, I don't think changing ereg() makes sense, as it has been deprecated as of PHP 7.0.0.
Existing code using (mb_)ereg() falls into two categories: code that does properly respect the current behavior (either by setting $regs to an explicit default before calling (mb_)ereg(), or by checking the return value of (mb_)ereg() before accessing $regs), and code that doesn't. The suggested change would only affect the latter, so one might argue that the BC break is acceptable (we might even fix such broken code).
So, I'm not sure what to do here (except wrt. the docs, which have to be fixed).
What do others think?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually, it had already been deprecated as of PHP 5.3.0, and removed as of PHP 7.0.0.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@cmb69 Sorry I don't understand exactly what you mean. Should I close this PR or do you think it is useful ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I still think it is useful, as I prefer the behavior it introduces (same as preg_match()), and as it would fix the issue with the currently wrong function prototype (
array $regs
). However, firstly I considered it important to fix the docs (which I considered badly written), and secondly I'm still unsure to which PHP version this PR should be applied to (I would suggest at least master, i.e. PHP 7.2, but maybe even targetting PHP 5.6+ is appropriate).There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Totally agree on that. I was thinking myself of adding an entire chapter dedicated to the Oniguruma pattern syntax and the similarities/differences with PCRE.
Do you think I should start ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, please! :-)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@cmb69 Okay I'm on it! 😉