Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:117178
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_5BC03F21-5554-45BE-A2AF-A23498A9550A"
Mime-Version: 1.0 (Mac OS X Mail 15.0 \(3693.60.0.1.1\))
Date: Tue, 1 Mar 2022 14:06:43 +0100
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>
To: php internals <internals@lists.php.net>
In-Reply-To: <0b5bc29d-3814-0e1d-b94a-47790019c778@gmx.de>
Message-ID: <5463E9FF-309D-4CFA-B709-81498B934059@cschneid.com>
Subject: Re: [PHP-DEV] Allowing NULL for some internal functions
From: cschneid@cschneid.com (Christian Schneider)

--Apple-Mail=_5BC03F21-5554-45BE-A2AF-A23498A9550A
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Am 01.03.2022 um 11:43 schrieb Christoph M. Becker <cmbecker69@gmx.de>:
> On 28.02.2022 at 23:11, Christian Schneider wrote:
>=20
>> Am 28.02.2022 um 22:05 schrieb Christoph M. Becker =
<cmbecker69@gmx.de>:
>>=20
>>> On 28.02.2022 at 21:51, Craig Francis wrote:
>>>=20
>>>> And after all of this, no-one has come up with a way to find or =
address
>>>> this problem, e.g.
>>>>=20
>>>> <?php
>>>> $nullable =3D ($_GET['a'] ?? NULL);
>>>> echo htmlentities($nullable);
>>>> ?>
>>>=20
>>> <?php
>>> function my_htmlentities(string|null $value) {
>>>   return htmlentities($value ?? "");
>>> }
>>>=20
>>> $nullable =3D ($_GET['a'] ?? NULL);
>>> echo my_htmlentities($nullable);
>>> ?>
>>>=20
>>> The BC break doesn't appear to be that serious after all.
>>=20
>> I'm not sure I get your point here: If you provide a user-land =
implementation of the previous behavior under a different name then the =
BC break cannot be serious?
>=20
> I said, the BC break doesn't appear to be *that* serious.
>=20
> To elaborate: in my opinion, it is a good thing if internal functions
> and userland functions behave the same regarding parameter types.


... just so it is mentioned as well (again, sorry): The other way of =
making internal functions behave like user land functions would be to =
change the definition of the internal function to
	function htmlentities(?string $value) { ... }
and casting it to string internally which would make the =
definition/documentation/behavior consistent while staying backward =
compatible.

And while a purist might think this is the end of the world because null =
is evil I'm still looking for evidence where this pragmatic approach =
would lead to a real harm or security issues going unnoticed.

Speaking of user land wrappers around internal functions: If you really =
are that worried about invalid input to something like htmlentities then =
I'd suggest that you add even more checks to your htmlentities-like =
function, e.g. checkout for double-encodings. If you're dealing with =
various data sources this will help you catch *visible* problems. And a =
check for null can be very easily added there if you want to ;-)

I guess my conclusion is that the BC break ("damage") for these basic =
functions is not worth it since you need more checks in user land than =
relying on the relatively basic PHP type system ("benefit") in any real =
world application.

That's why I'm advocating for consistency by changing these basic =
function definitions instead of their behaviors.

- Chris


--Apple-Mail=_5BC03F21-5554-45BE-A2AF-A23498A9550A--