Re: BC break in master (7.2) - Distinguish between unmatched subpatterns and empty matches in preg_*()
| From: | Nicolas Grekas | Date: | Tue, 16 May 2017 10:51:20 +0000 |
| Subject: | Re: BC break in master (7.2) - Distinguish between unmatched subpatterns and empty matches in preg_*() | ||
| References: | 1 2 3 4 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-99058@lists.php.net to get a copy of this message | ||
2017-05-15 17:21 GMT+02:00 Sara Golemon <pollita@php.net>:
> On Mon, May 15, 2017 at 6:36 AM, Nicolas Grekas
> <nicolas.grekas@gmail.com> wrote:
> >> I agree that a minimum 5 years old possible bug, quite small, causing
> >> BC breaks is not good. As far as the fix is critical or justified, I
> >> think it is sometimes ok to break BC for edge cases. However I do not
> >> see this is not the case here.
> >>
> >
> > Another possibility would be to make this opt-in, with a new flag.
> > FYI, I quickly spotted at least two places in the code base where we
> check
> > the matches with something like:
> >
> > if ('' !== $matches[2]) {...} else {...}
> >
> > This should be a pretty common check so the BC break will impact more
> > userland code when released.
> >
> I agree with the original bug report that being able to distinguish
> between not-matched and empty-match is a useful and meaningful
> distinction, and since most users won't care, then the decision to
> just do it was *probably* right at the time. Given the observation
> about strict equality checks (which I don't have the data for, but it
> rings true) it does seem optimistic in *handsight*.
>
> Given that, I'd recommend a middle-ground such as the opt-in behavior
> described here.
Here is a PR implementing the new flag:
https://github.com/php/php-src/pull/2526
Nicolas