Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:116993 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 47632 invoked from network); 7 Feb 2022 11:18:23 -0000 Received: from unknown (HELO localhost.localdomain) (76.75.200.58) by pb1.pair.com with SMTP; 7 Feb 2022 11:18:23 -0000 To: internals@lists.php.net Date: Mon, 7 Feb 2022 12:34:04 +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> 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 12:05, Craig Francis wrote: > And specifically with NULL, strings in C are a "one-dimensional array of > characters terminated by a null character", so you could say that NULL is > very similar to an empty string - maybe that helps address the "pretend its > a string" objection? In this case we're talking about the difference between a char* that points to a 1 byte buffer containing '\0' and a char* that itself points to NULL. Trying to perform string operations on a null pointer in C would equally blow up. With regards to your framework comment, any framework worth its salt will also have the option to provide a default value other than null when the value is not provided. It is the responsibility of the user to make use of this functionality to provide the correct type for what the soon-to-be-called function is expecting. Mark Randall