Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:117211
Message-ID: <f1e4ccde-fd1f-68c9-79ad-0a3ccfc8f77a@gmx.net>
Date: Wed, 2 Mar 2022 15:58:25 +0100
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
 Thunderbird/91.6.1
Content-Language: en-US
To: internals@lists.php.net
References: <CAFv4g+Efz-V5V1uUedXpusNw6z-on=TT3kdWgC66SptSd8kB4g@mail.gmail.com>
 <CAFv4g+GDsq=w7qtSOVptEBiTTDZk2aeFCVGThVBR=0-xk=0oAA@mail.gmail.com>
 <983552d8-11f1-b5bc-fb82-148347982fda@gmx.de>
 <5494eaa7-2fa6-8364-9683-a2c8c9789d81@gmail.com>
 <CAC5V6gjianVuPo654_-mETYxsu0-eSo++Ez1yy81MNEcfwFq1Q@mail.gmail.com>
 <69642616-72b7-44fe-97a7-27ae03bc8fce@www.fastmail.com>
 <CAFv4g+F0HOgCgeUyiG06qhxQnWbVCN2aaP=a2CJT9tkbMP7kLg@mail.gmail.com>
 <7fbed755-42e2-d023-285f-39863a97f297@gmx.de>
 <3665C848-B4C3-4528-AEFA-02C868748AA8@cschneid.com>
 <0b5bc29d-3814-0e1d-b94a-47790019c778@gmx.de>
 <CAFv4g+HPm+edmgnPAGwBk=4EJxj2can--iWfgtMasrYHk6pLww@mail.gmail.com>
 <4bff3f23-a3ec-4416-f44e-1f4f5d7e0caa@gmail.com>
 <CAFv4g+E159xoR4hxtsay-FamCSrJN+DmodvjzYGHcd1pQFsX+Q@mail.gmail.com>
 <2d06bc12-7d7e-4a88-b823-de64642381e6@www.fastmail.com>
 <CAFv4g+GATfXiACNk01V-RWURgsyeN11-db+yoj0R_tGOMG-2tg@mail.gmail.com>
In-Reply-To: <CAFv4g+GATfXiACNk01V-RWURgsyeN11-db+yoj0R_tGOMG-2tg@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] Allowing NULL for some internal functions
From: a.leathley@gmx.net (Andreas Leathley)

On 02.03.22 15:27, Craig Francis wrote:
> On Wed, 2 Mar 2022 at 14:17, Larry Garfield <larry@garfieldtech.com> wro=
te:
>
>> Null is not an empty string.  Null is not a string.  Null is not 0.  Nu=
ll
>> is not an integer.
>
> So what should this do?
>
> $name =3D ($_POST['name'] ?? NULL);
>
> var_dump($name =3D=3D '');
>
> Is that now going to be false?
>
Comparisons with =3D=3D are quite worthless, except when comparing objects=
,
as =3D=3D has so many caveats for when it returns true because of weird
rules about what should be considered equal or not for legacy reasons. I
don't think I have used =3D=3D in the last 5 years, and life has gotten so
much better because of it.

Why not write:

$name =3D ($_POST['name'] ?? '');

Then you know 100% that $name does not contain null. It might not be a
string, but it cannot be null. You can still not safely pass it to
something like htmlentities or str_starts_with, because $name could be
an array. And I think that is the reason why the current deprecation and
eventual removal makes sense - it highlights missing logic that can
easily lead to errors. If the problem is not null, then it might be that
you have another unexpected type like an array, because the value was
not properly checked. Putting strval around such code (as one
possibility to resolve it) at least improves the code, in that we then
have a clear type for the variable, removing some room for errors and bugs=
.