Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:116987 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 10507 invoked from network); 7 Feb 2022 00:12:30 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 7 Feb 2022 00:12:30 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 5E6721804AC for ; Sun, 6 Feb 2022 17:28:06 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=-0.2 required=5.0 tests=BAYES_20,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,HTML_MESSAGE,RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.2 X-Spam-ASN: AS15169 209.85.128.0/17 X-Spam-Virus: No X-Envelope-From: Received: from mail-lj1-f170.google.com (mail-lj1-f170.google.com [209.85.208.170]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Sun, 6 Feb 2022 17:28:05 -0800 (PST) Received: by mail-lj1-f170.google.com with SMTP id k18so5371501lji.12 for ; Sun, 06 Feb 2022 17:28:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=craigfrancis.co.uk; s=default; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=pRE7F44iKwSheS/YhwiExcTHNAQDWdM8yLAiVHMc2zI=; b=dUVSyN3wfvPzzLWSImgoU79Hrj4dUt5IDUNCkPlmxCRs+rZ2sZPHdlaUYR16ZbUYQW YoGtqqMGvdFmuHIOGEoGDS8nI7nggaiXb7xzmCTJwmS8kvu8QWcMVs2zyIGG9FHcLNIT oruyayT6kwHK/EbQKunC5kgx5eYNcASHHIcEA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=pRE7F44iKwSheS/YhwiExcTHNAQDWdM8yLAiVHMc2zI=; b=RFWSBpUtGSS6QNEAEm5xq2h9A8RadmRmfbapMCkjzUui3SrjdNRlpMJ4+rRx1osaaJ gsLLAuv6hqzLwqkvIzt5o0XQ7um1U7x0s5Zm7mtpRE+c+WlqdezLZzm72uQuh21COmz/ akGAjGy9VbWXJ2MWnff86N3U6Az3mIie97Ov9Az5R3GiaTVQB9QLKPPrFbyGic5x+81i bJfaXTRJ/di3/HzjVSHeNICwH3/HsmgH9Nkteeq820Cuym11fIBxg0gVKwBAE6TndbaF NXX4OO4xmvMDiNU7BcsHRregbNfBGv309K4HcXFRcmSnTfpyjIls3Hiw/F8mcEiReCO2 TayA== X-Gm-Message-State: AOAM533pkzrXf6tzffCrLYAzSQNgNxL0AhhlMh/eiWIXBJlhP4AJcAhu 2stAqV+CyOE83L2D0cqIZssQFhoFoBfMiyapEv2VhodUKi2g/g== X-Google-Smtp-Source: ABdhPJxfWtfhQpNRLCFmPalrvsh6UUTrrRkKhci1z+BavGWmc1eCKz/ZH0/G7xQs4ayamUFa4OyFXWcB/qG73T4EHbM= X-Received: by 2002:a2e:a5c3:: with SMTP id n3mr7188568ljp.212.1644197284122; Sun, 06 Feb 2022 17:28:04 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: Date: Mon, 7 Feb 2022 01:27:53 +0000 Message-ID: To: PHP internals Content-Type: multipart/alternative; boundary="0000000000000fab5a05d7638397" Subject: Re: [PHP-DEV] Allowing NULL for some internal functions From: craig@craigfrancis.co.uk (Craig Francis) --0000000000000fab5a05d7638397 Content-Type: text/plain; charset="UTF-8" On Sat, 1 Jan 2022 at 23:17, Craig Francis wrote: > Draft RFC: > https://wiki.php.net/rfc/allow_null > I know, I'm a glutton for punishment, but I've started writing a patch for this: https://github.com/craigfrancis/php-src/compare/master...allow-null It does not affect any Fatal Error exceptions for scripts using 'strict_types'. For now it simply defines `Z_PARAM_STR_ALLOW_NULL`; it's not used by any functions yet (that's the next step). It works a bit like `Z_PARAM_STR_OR_NULL` (but it will return an empty string instead of NULL). It should be a fairly easy drop in replacement for `Z_PARAM_STR`. e.g. To update `htmlspecialchars()`, and related functions, I'd simply update this line: https://github.com/php/php-src/blob/7b90ebeb3f954123915f6d62fb7b2cd3fdf3c6ec/ext/standard/html.c#L1324 Please note I'm not a C programmer, and I barely understand the code base, so constructive/friendly feedback is welcome. Thanks, Craig Extra notes... No-one has given a single reason why any one of the listed functions should not allow `NULL`; that said, I appreciate that developers using `strict_types` do prefer this (and they will not be affected by this). I've not seen any suggestion on how Rector, PHPCompatibility, or anything else could provide a way to fix this issue automatically. Only very strict static analysis (e.g. Psalm at levels 1 to 3, with no baseline) currently picks up this issue. I am simply trying to "relax certain type requirements on a case by case basis" (which will help upgrading to PHP 9); ref the original discussion: https://externals.io/message/112327 I know one person simply said this was a "terrible idea", but I'm still waiting to hear any details on why. In response to the "it's a bit late" position; we only have a deprecation at the moment (can be ignored), it will be too late when PHP 9 starts raising Fatal Error exceptions for anyone committing the heinous crime of passing NULL to these functions (for reference, WordPress aren't exactly rushing to fix this one). The change in behaviour is done in `zend_parse_arg_str_weak()`, so I don't think it will make much of a performance difference; but considering how much effort went in to testing `is_literal()`, and how people still managed to mis-read that, and how other RFCs don't mention performance *details* at all, I'm skipping that bit of pain. And yes, I have seen the -4 on externals.io... thank you for that . --0000000000000fab5a05d7638397--