Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:113350
Content-Type: multipart/signed;
	boundary="Apple-Mail=_DFC1F853-B97C-4DA0-9D75-AD913AB84F8E";
	protocol="application/pgp-signature";
	micalg=pgp-sha256
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\))
Date: Wed, 3 Mar 2021 09:36:49 -0600
References: <CAF+90c-93pAMM3XYrj=G_Z+uaTRTgzdEOULYwKUj7Hp64FBp6w@mail.gmail.com>
To: PHP internals <internals@lists.php.net>
In-Reply-To: <CAF+90c-93pAMM3XYrj=G_Z+uaTRTgzdEOULYwKUj7Hp64FBp6w@mail.gmail.com>
Message-ID: <24AAE646-160C-451D-BCAB-F112623D17A7@benramsey.com>
Subject: Re: [PHP-DEV] Don't compare zero exponentials in strings as equal
From: ben@benramsey.com (Ben Ramsey)

--Apple-Mail=_DFC1F853-B97C-4DA0-9D75-AD913AB84F8E
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

> On Mar 3, 2021, at 08:04, Nikita Popov <nikita.ppv@gmail.com> wrote:
>=20
> Hi internals,
>=20
> PHP's =3D=3D comparison semantics for strings have a peculiar =
edge-case, where
> comparisons of the form "0e123" =3D=3D "0e456" return true, because =
they are
> interpreted as floating point zero numbers. This is problematic, =
because
> strings of that form are usually not numbers, but hex-encoded hashes =
or
> similar.
>=20
> I'm wondering if it may make sense to special-case the comparison =
semantics
> to not consider strings of the form "0e[DIGITS]" equal, unless they =
are
> exactly equal (i.e., fall back to lexicographical if both sides of the
> comparison are zero exponentials).
>=20
> Here's a possible implementation: =
https://github.com/php/php-src/pull/6749
>=20
> Of course, the usual rule that you should always use =3D=3D=3D still =
holds, but
> this at least eliminates the most dangerous edge case.


I encountered a similar situation a few years back.

We were testing whether a value was numeric and, if so, adding 0 to it =
in order to convert it to an appropriate number type. The code looked =
something like this:

    if (is_numeric($value)) {
        $value +=3D 0;
    }

We chose not to do an explicit cast because the string could represent a =
float or an int, so we wanted the type coercion to do its magic.

We did this before calling `json_encode()` on the data structure, so =
that string numbers coming out of a database would be converted to =
numbers in JSON. For some reason, `JSON_NUMERIC_CHECK` wasn=E2=80=99t =
giving us what we wanted, but I can=E2=80=99t recall the issue we were =
having.

Anyway, we ran into some fun issues with hashes that looked like this:

    '131124826899e4096767887418316466'

That value should have remained a string in the JSON output, but =
`is_numeric()` returns `true` for it, so it became `INF`.

We were able to come up with a work-around, but it=E2=80=99s not =
foolproof.

Cheers,
Ben


--Apple-Mail=_DFC1F853-B97C-4DA0-9D75-AD913AB84F8E
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP

-----BEGIN PGP SIGNATURE-----

iHUEAREIAB0WIQToXQMR3fpbrPOmEOewLZeYnIwHGwUCYD+tEQAKCRCwLZeYnIwH
GySJAP90Tt+1vJkFwb0GdVKHRIwIKt+nP5PU5saOd68G7D/iDQD8Dm4U05ezA2zZ
lhbnvrLujQmmlvKMWCDPTgKuUtfBxO4=
=bsnu
-----END PGP SIGNATURE-----

--Apple-Mail=_DFC1F853-B97C-4DA0-9D75-AD913AB84F8E--