Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:97457
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zend.com designates 104.47.38.112 as permitted sender)
To: PHP internals <internals@lists.php.net>
Thread-Topic: Fix for issue #72320 - compatibility breakage in 7.0.11
Thread-Index: AdJcZQpwolNShFY3Skaf3n6dVLSIng==
Date: Thu, 22 Dec 2016 15:13:50 +0000
Message-ID: <BY2PR02MB298106B3E23A1E779593A6FAC920@BY2PR02MB298.namprd02.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
received-spf: None (protection.outlook.com: zend.com does not designate
 permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Dec 2016 15:13:50.7989
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 32210298-c08b-4829-8097-6b12c025a892
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR02MB298
Subject: Fix for issue #72320 - compatibility breakage in 7.0.11
From: zeev@zend.com (Zeev Suraski)

All,

In 7.0.11, the behavior of iconv_substr() was changed so that if the length=
 argument is equal to the length of the string - an empty string is returne=
d, as opposed to FALSE.

While I think there's a case to be made that this makes sense - what worrie=
s me is that we've introduced a behavioral change for a function in a bugfi=
x release - one that has bitten us in Zend Framework - and I think it's saf=
e to assume that it will affect plenty of other codebases.

Personally, I think we should be *much* more selective about introducing be=
havioral changes in maintenance releases, even if they can be considered bu=
gfixes.  Depending on their scope and impact, they should either go into th=
e next mini version (this one probably falls in that category) or the next =
major version.  Of course - there are plenty of bugfixes where the existing=
 behavior is a crash, or undefined/unpredictable - those are obviously fine=
 to fix without further discussion.  I'm talking about the cases where the =
current behavior is very much defined and has been that way for a long time=
, but for whatever reason, people think it should change.

We've worked hard to establish trust that people can upgrade into the next =
maintenance version with minimal testing - which greatly helps people keep =
current with the latest and greatest fixes incl. security, and even the nex=
t minor version with relatively limited testing, when we ensured downwards =
compatibility within these versions.  It does mean that our finger needs to=
 be a lot more hesitant on the trigger when we evaluate behavioral changes =
such as these.

It's arguably too late to revert this patch now, but I think it's a good op=
portunity to discuss the guidelines for dealing with such issues.

Thoughts?

Zeev
  	=20