Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:113366
MIME-Version: 1.0
References: <CAF+90c-93pAMM3XYrj=G_Z+uaTRTgzdEOULYwKUj7Hp64FBp6w@mail.gmail.com>
 <c79fe1ef-433a-72d7-9b89-ae279b39a1f5@gmail.com> <E0DF66AE-A0DC-4715-8771-5D9EC81A6BFB@cschneid.com>
 <CAGBsUrdEsW2ZhRpmus=6C5gnWvh=CJEA59Edtr7sZ+s2zTVPGw@mail.gmail.com>
 <424A5E98-2110-4AFE-9C53-8636A6140313@benramsey.com> <F1D9E7C0-96D3-480C-AE9B-E5559FD8D861@cschneid.com>
 <CAF+90c8u_x3ZOADesgwauxuUjy+a2D+r+Q60OOgqZD3vC9QYeQ@mail.gmail.com>
In-Reply-To: <CAF+90c8u_x3ZOADesgwauxuUjy+a2D+r+Q60OOgqZD3vC9QYeQ@mail.gmail.com>
Date: Thu, 4 Mar 2021 12:13:57 +0100
Message-ID: <CAF+90c-GdW4waV-gRmSOs08qr0nMo5r69zj8nVvu-ZE7eJ=xyQ@mail.gmail.com>
To: Christian Schneider <cschneid@cschneid.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="00000000000041730405bcb41117"
Subject: Re: [PHP-DEV] Don't compare zero exponentials in strings as equal
From: nikita.ppv@gmail.com (Nikita Popov)

--00000000000041730405bcb41117
Content-Type: text/plain; charset="UTF-8"

On Thu, Mar 4, 2021 at 11:54 AM Nikita Popov <nikita.ppv@gmail.com> wrote:

> On Thu, Mar 4, 2021 at 10:54 AM Christian Schneider <cschneid@cschneid.com>
> wrote:
>
>> Am 04.03.2021 um 01:37 schrieb Ben Ramsey <ben@benramsey.com>:
>> > On Mar 3, 2021, at 14:25, Kamil Tekiela <tekiela246@gmail.com> wrote:
>> >>
>> >> when both are strings then chances are that this is an error.
>> >
>> > Except when comparing two values from sources known to provide numbers
>> as strings, such as form input and database results. :-)
>>
>>
>> This would be a problem for leading zeroes and leading/training spaces,
>> right?
>>
>> Leading zeroes theoretically could happen in databases, leading/training
>> spaces happen in form input and possibly databases.
>> Are there other 'common' cases?
>>
>
> The main one that comes to mind is something like '0' == '0.0'. However,
> the real problem is something else: Comparison behavior doesn't affect just
> == and !=, but also < and >. And I can see how people would want '2' < '10'
> to be true (numeric comparison) rather than false (lexicographical
> comparison).
>
> I generally agree that we should remove the special "numeric string"
> handling for equality comparisons, and I don't think that removing that
> behavior would have a major impact. But we do need to carefully consider
> the impact it has on relational operators. There are two ways I can see
> this going:
>
> 1. Decouple equality comparison from relational comparison. Don't handle
> numeric strings for == and !=, but do handle them for <, >, etc. The
> disadvantage is that comparison results may not be trichotomous, e.g. for
> "0" op "0.0" all of ==, < and > would return false. (To be fair, this can
> already happen in other cases, e.g. non-comparable objects.)
>
> 2. Don't allow relational comparison on strings. If you want to compare
> them lexicographically, use strcmp(), otherwise cast to number first.
> ("Don't allow" here could be a warning to start with.)
>

Regarding the last point, while I think that lexicographical comparison
with explicit < and > operators is pretty uncommon, sorting an array of
strings and expecting lexicographical order probably isn't unusual. While
SORT_STRING can be passed to enforce that, people probably expect that as
the default behavior. So just not allowing relational comparison is not a
great option either.

Nikita

--00000000000041730405bcb41117--