Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:76615
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain lerdorf.com from 209.85.192.178 cause and error)
Message-ID: <53F114D0.2070305@lerdorf.com>
Date: Sun, 17 Aug 2014 13:47:12 -0700
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Sara Golemon <pollita@php.net>, Marc Bennewitz <php@mabe.berlin>
CC: PHP internals <internals@lists.php.net>
References: <53F1094B.4040100@mabe.berlin> <CAESVnVr3QJ56Ynu1cN+745fZEkq+Qas=5ecvQcF0jBX7QhdaMg@mail.gmail.com>
In-Reply-To: <CAESVnVr3QJ56Ynu1cN+745fZEkq+Qas=5ecvQcF0jBX7QhdaMg@mail.gmail.com>
Content-Type: multipart/signed; micalg=pgp-sha1;
 protocol="application/pgp-signature";
 boundary="WITigAO2uhC1656eoFp9Ln0MPgVwrHNso"
Subject: Re: [PHP-DEV] [RFC] Binary String Comparison
From: rasmus@lerdorf.com (Rasmus Lerdorf)

--WITigAO2uhC1656eoFp9Ln0MPgVwrHNso
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 8/17/14, 1:18 PM, Sara Golemon wrote:
> On Sun, Aug 17, 2014 at 12:58 PM, Marc Bennewitz <php@mabe.berlin> wrot=
e:
>> I've created a draft RFC and patch to change the behavior of non-stric=
t
>> string to string comparison to be binary safe (as the strict compariso=
n
>> operator does):
>>
>>      https://wiki.php.net/rfc/binary_string_comparison
>>
> If I understand your goal correctly, you seem to want to change a very
> fundamental (and ancient) behavior of the language even though
> mechanisms already exist to do what you describe as the "changed
> behavior".
>=20
> What exactly is wrong with =3D=3D=3D, strcmp(), etc..?

Yes, this would be a very problematic change at this point. It isn't
something you could audit your code for easily and make it future-proof.
Something that used to work will simply not and it will be nearly
impossible to understand why.

I don't necessarily disagree that this is perhaps the way it should have
worked from the beginning, but without an upgrade path I don't think we
can do this. The only mention in your RFC towards this is:

   This can be easily resolved by explicitly casting one of the
   operands to an integer or float respectively define the sorting
   algorithm."

That is not an upgrade path. Going through and auditing every single
comparison in a large code base to see if one side should perhaps be
cast to a different type is not feasible.

-Rasmus


--WITigAO2uhC1656eoFp9Ln0MPgVwrHNso
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
Comment: GPGTools - https://gpgtools.org

iEYEARECAAYFAlPxFNAACgkQlxayKTuqOuDhqgCgig6aHQe+PYGMxnSMLhpEf/kr
gSIAnis2bHalQRWRerLiBPjlFZ+NoC+L
=pWpS
-----END PGP SIGNATURE-----

--WITigAO2uhC1656eoFp9Ln0MPgVwrHNso--