Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:117002 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 71907 invoked from network); 7 Feb 2022 15:49:39 -0000 Received: from unknown (HELO localhost.localdomain) (76.75.200.58) by pb1.pair.com with SMTP; 7 Feb 2022 15:49:39 -0000 To: internals@lists.php.net Date: Mon, 7 Feb 2022 17:05:25 +0000 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.5.1 References: <6200d9f4.1c69fb81.1d3f2.8b60SMTPIN_ADDED_MISSING@mx.google.com> <620111c5.1c69fb81.c49f5.c38aSMTPIN_ADDED_MISSING@mx.google.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Posted-By: 87.81.129.66 Subject: Re: [PHP-DEV] Allowing NULL for some internal functions From: marandall@php.net (Mark Randall) Message-ID: On 07/02/2022 15:34, Craig Francis wrote: > So are you suggesting that all the frameworks should change their default > to an empty string? or every single project should update every use of > these input functions to always override this default, or cast the received > value to always be a string? all to avoid a Fatal Error if a NULL value > ever dared to be passed to `htmlspecialchars()` and similar functions in > PHP 9? I'm suggesting that every project should be specifying the default they want when they call the function. If by omission you call a function in a way that effectively says 'give me a null', then don't be surprised if it breaks when it gives you what you asked for and you pass it to something that wasn't designed for it. Special casing things is almost always the wrong approach and will lead to pain in the long run. Like "0" being the only non-empty string that's falsey.