Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:117819
MIME-Version: 1.0
References: <CAFv4g+Ej4JbM9SzQ0iU-d8C4T+2XNo=8jnJ1uwfQ=skZZXx9Tg@mail.gmail.com>
 <1755E8B5-229B-47B2-BBAF-B5E014F5473D@craigfrancis.co.uk> <1180af01-080f-ee0a-3159-74bf7e0a8aea@gmail.com>
 <73F563E2-7C31-4B5E-A6B9-AE1BD05ADD1C@craigfrancis.co.uk> <24d35dc8-bd1d-3d90-99ac-ebdcc3b2a9e4@gmail.com>
 <B835482D-FB65-4022-BE5F-2E4E3E72B360@craigfrancis.co.uk>
In-Reply-To: <B835482D-FB65-4022-BE5F-2E4E3E72B360@craigfrancis.co.uk>
Date: Sat, 28 May 2022 14:42:29 -0500
Message-ID: <CANvqVdpLmGQQF1aHkH4QfdcKGuG8+5FMFfKZeag2QsPTNcbdXg@mail.gmail.com>
To: internals@lists.php.net
Content-Type: multipart/alternative; boundary="000000000000b36f6b05e017aacb"
Subject: Re: [PHP-DEV] NULL Coercion Consistency
From: michael.babker@gmail.com (Michael Babker)

--000000000000b36f6b05e017aacb
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, May 27, 2022 at 9:36 PM Craig Francis <craig@craigfrancis.co.uk>
wrote:

> I know I keep going on about this very simply example, but it represents =
a
> fairly typical style of programming PHP, and I just do not understand wha=
t
> the problem with it is:
>
> ```
> $search =3D $request->input('q'); // Laravel, returns NULL when 'q' is no=
t
> defined.
>
> echo 'Results for ' . htmlspecialchars($search);
> ```


If you want to go with this specific example, exactly as written, here is
the exact issue I have with it.

As already mentioned, `htmlspecialchars()` is documented and the
implementing code requires a string argument.  Passing a null value to it
requires explicitly writing non-typesafe code, and requires understanding
of how the PHP language handles type coercion, and how those rules are
different based on whether the file calling that function has the
`strict_types` declaration.  So on a code review, I have to understand the
context of the value passed through and know what context the language is
operating in to determine if non-string values are allowed to avoid errors,
and understand the semantics of PHP=E2=80=99s type coercion system to make =
sure the
output is something expected based on the input.  Compare that to knowing
the function explicitly only accepts a string value and you know you are
working with a string through appropriate validation; for me, even in a
loosely typed environment, I=E2=80=99d rather follow the documented paramet=
er types
instead of having to worry about all the other magic involved to make null
work.

Though, that input variable would never reach output in any of my projects
to begin with if it were null or an empty string; both would land on a code
path treated as no search being performed.  So that example for me is also
way oversimplified because it doesn=E2=80=99t match a real world workflow I=
MO.

On Fri, May 27, 2022 at 9:36 PM Craig Francis <craig@craigfrancis.co.uk>
wrote:

> Sorry, but I'm not following... if there is a benefit/reason for PHP to
> reject NULL for `htmlspecialchars()`, and I'm just too stupid to see what
> it is, I would have assumed that benefit/reason would also apply to the
> HTML encoding function `e()` in Laravel.


No, that would not automatically apply to Laravel=E2=80=99s helper function=
, or any
escaping functions in Twig, or escaping functions used in platforms without
templating frameworks like WordPress.  If it=E2=80=99s not OK for functions=
 that
can call `htmlspecialchars()` to gracefully handle null to make sure those
trigger the same type error as the core language, then along the same
lines, I would argue that patches which add null coalescing or explicit
typecasting to that parameter in libraries or applications should also be
rejected because then they=E2=80=99re masking an error the language purpose=
fully
elected to emit.

>
--=20
- Michael Please pardon any errors, this message was sent from my iPhone.

--000000000000b36f6b05e017aacb--