Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:99058
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.214.49 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAESVnVrmPxg2cQrLNKXT1y4Pdg7LAEtHKZRa2+UtLFvSkPfCvQ@mail.gmail.com>
References: <CAOWwgpm3Sq0nLeVcgXdGAjtcaQGuLgK=oTJRWFvQay4dDUWiXw@mail.gmail.com>
 <CAEZPtU5i5+LEmQkHgh1MAJ4XQi3uzaoeiQRJrNvp5Z26sE0kZA@mail.gmail.com>
 <CAOWwgpkcDqWUX=KAYXC73bB_4k66rG+AjPpCX8kEnUaWnJ69vA@mail.gmail.com> <CAESVnVrmPxg2cQrLNKXT1y4Pdg7LAEtHKZRa2+UtLFvSkPfCvQ@mail.gmail.com>
Date: Tue, 16 May 2017 12:51:20 +0200
Message-ID: <CAOWwgp=AC0TS1xLCmS_kEazcP7daupj0-6-_GTUNJHYjHrNaGw@mail.gmail.com>
To: Sara Golemon <pollita@php.net>, Remi Collet <remi@fedoraproject.org>, 
	"Christoph M. Becker" <cmbecker69@gmx.de>
Cc: Pierre Joye <pierre.php@gmail.com>, 
	"internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="001a114a9bbae8f034054fa1f474"
Subject: Re: [PHP-DEV] BC break in master (7.2) - Distinguish between
 unmatched subpatterns and empty matches in preg_*()
From: nicolas.grekas@gmail.com (Nicolas Grekas)

--001a114a9bbae8f034054fa1f474
Content-Type: text/plain; charset="UTF-8"

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

--001a114a9bbae8f034054fa1f474--