Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:104522
MIME-Version: 1.0
References: <CAF+90c821boRO6YsO0SH0JbDb8E8eTHfEK=e4Y5_z9P7+OOnUg@mail.gmail.com>
 <CALKiJKoSbrq=GYDY1Rsch2pbDft7piw1xkKXs97xYaA8DrytQw@mail.gmail.com>
In-Reply-To: <CALKiJKoSbrq=GYDY1Rsch2pbDft7piw1xkKXs97xYaA8DrytQw@mail.gmail.com>
Date: Tue, 26 Feb 2019 14:26:24 +0100
Message-ID: <CAF+90c8A320QQo-LmsjATDM-uqcyNY5CzXtZRnY7crdwOzRUkQ@mail.gmail.com>
To: Rowan Collins <rowan.collins@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="00000000000001e7360582cc023b"
Subject: Re: [PHP-DEV] [RFC] Saner string to number comparisons
From: nikita.ppv@gmail.com (Nikita Popov)

--00000000000001e7360582cc023b
Content-Type: text/plain; charset="UTF-8"

On Tue, Feb 26, 2019 at 2:06 PM Rowan Collins <rowan.collins@gmail.com>
wrote:

> On Tue, 26 Feb 2019 at 12:27, Nikita Popov <nikita.ppv@gmail.com> wrote:
>
> > I'd like to bring forward an RFC for PHP 8 to change the semantics of ==
> > and other non-strict comparisons, when used between a number and a
> string:
> >
> > https://wiki.php.net/rfc/string_to_number_comparison
> >
>
>
> Hi Nikita,
>
> Thanks for tackling this; I think if we can improve this, we'll be
> answering a lot of language critics (I'm sure they'll find something else
> to complain about, but that's life!).
>
> However, I'm concerned that it doesn't go far enough, when you say that the
> following will still return true:
>
> 0 == "0e214987142012"
> "0" == "0e214987142012"
>
> I think the cases where this is useful are vastly outweighed by the cases
> where it's completely unexpected, and potentially dangerous (e.g. in a hash
> comparison). If this is not fixed, the "dogma to always avoid non-strict
> comparisons" you refer to will remain.
>
> If I understand it right, this arises from the fact that "0e214987142012"
> is considered a "well-formed numeric string", which is cast to int(0) or
> float(0). Is it feasible to also narrow this definition as part of the same
> change?
>

Yes, that's right. However, it's probably worth mentioning that string to
string comparisons are subject to additional constraints beyond the
well-formedness requirement. Since PHP 5.4.4 there are additional overflow
protections in place, which prevent numeric comparison from applying when
both sides are integers that overflow to double and become equal as a
result of that. This means that "100000000000000000000" ==
"100000000000000000001" returns false rather than true since PHP 5.4.4.

I'm mentioning this, because it is a precedent for tweaking the string to
string numeric comparison rules to prevent unexpected and possibly security
critical equalities. I think we could add similar special handling for the
"0eNNNN" == "0eMMMM" case, as this is another "catastrophic" case when it
comes to comparisons of hashes that happen to start with 0e, for example.

It might be better to discuss such a change separately from this proposal
though (it's much more minor, and something that can also conceivable go
into a minor version, given that the previous change was applied in a patch
release).

Regards,
Nikita

--00000000000001e7360582cc023b--