Am 01.03.2022 um 11:43 schrieb Christoph M. Becker <cmbecke...@gmx.de>:
> On 28.02.2022 at 23:11, Christian Schneider wrote:
> 
>> Am 28.02.2022 um 22:05 schrieb Christoph M. Becker <cmbecke...@gmx.de>:
>> 
>>> On 28.02.2022 at 21:51, Craig Francis wrote:
>>> 
>>>> And after all of this, no-one has come up with a way to find or address
>>>> this problem, e.g.
>>>> 
>>>> <?php
>>>> $nullable = ($_GET['a'] ?? NULL);
>>>> echo htmlentities($nullable);
>>>> ?>
>>> 
>>> <?php
>>> function my_htmlentities(string|null $value) {
>>>   return htmlentities($value ?? "");
>>> }
>>> 
>>> $nullable = ($_GET['a'] ?? NULL);
>>> echo my_htmlentities($nullable);
>>> ?>
>>> 
>>> The BC break doesn't appear to be that serious after all.
>> 
>> 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?
> 
> I said, the BC break doesn't appear to be *that* serious.
> 
> 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

Reply via email to