Re: BC break in master (7.2) - Distinguish between unmatched subpatterns and empty matches in preg_*()

From: 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

« previous php.internals (#99058) next »