On Tue, Feb 26, 2019 at 2:06 PM Rowan Collins <rowan.coll...@gmail.com> wrote:
> On Tue, 26 Feb 2019 at 12:27, Nikita Popov <nikita....@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
