Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:126716
Date: Tue, 11 Mar 2025 11:54:50 +0000
To: "Rowan Tommins [IMSoP]" <imsop.php@rwec.co.uk>
Cc: internals@lists.php.net
Subject: Re: [PHP-DEV] Consensus on argument validation for built-in functions
Message-ID: <CG7fDapdXYGFwt0ryH-8s-dXCBrVw7gSIpgYYvKRDg_mlTjjuyro5uy1V5JLKzf21if2GLbjNv5zJ6M-7Szkj5URUdyXQWIZ0_b2wNUKbVE=@gpb.moe>
In-Reply-To: <C0CFBD16-810E-4D4D-B818-4CB0E89DE25A@rwec.co.uk>
References: <CAPTD5yHhpcJJDNWMCpQSrkGyY5+YtgKUy1OKYv5t03KyzoAXbA@mail.gmail.com> <XOTiGCaoOV5bvCQP2nMZW7AzIoOdH5la7sgmJ8KK51Z6n9zJLiAM7cYTiUhH5zsrrMbMUZe257bmPe8SgcNgN2IqNzPUty68egntFngnsXU=@gpb.moe> <C3E24D9F-3D72-401F-81A9-CAA245308703@cschneid.com> <041d1a8c-dd43-4592-b997-ad4d2f91aeac@app.fastmail.com> <C0CFBD16-810E-4D4D-B818-4CB0E89DE25A@rwec.co.uk>
Feedback-ID: 96993444:user:proton
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: internals@gpb.moe ("Gina P. Banyard")

On Tuesday, 11 March 2025 at 11:12, Rowan Tommins [IMSoP] <imsop.php@rwec.c=
o.uk> wrote:

>=20
> On 11 March 2025 10:20:52 GMT, Rob Landers rob@bottled.codes wrote:
>=20
> > Well, when you make it an exception, it usually gets upgraded/fixed fas=
ter :)
>=20
>=20
> Not necessarily. When people see long lists of breaking changes in a rele=
ase, they may just put off upgrading / marking the library compatible.
>=20
> I think we should be very wary of how far we bend the difference between =
"minor" and "major" releases.
>=20
> For these changes, I'd like to hear the argument against starting with a =
Warning. Is there any significant burden to waiting until 9.0 for these to =
become errors?
>=20
> Rowan Tommins
> [IMSoP]

Consistency.
Just staring at ext/pcntl and the git blame you can see that some functions=
 validate the signal number (or flags) since PHP 8.0, others do not or only=
 recently (commit from November 2023).
The reason being that the code was inconsistent in when it would actually w=
arn in the first place.

The other one is data loss concerns, many functions that forward strings to=
 C APIs don't check that they do not contain nul bytes, and thus the C API =
receives a truncated string.
Or C API require a C int, which is 32bit compared to a PHP int which can be=
 64 bit, so truncation may happen for large negative/positive values.

It also means that we need to do *multiple* passes, on the same code path, =
resulting in somewhat of a code churn and possibly not using a common abstr=
action.
Considering that we didn't even have the time to properly remove some depre=
cations from PHP 7 with the PHP 8.0.0 release, nor convert all relevant E_W=
ARNINGs to Value/Type errors, I expect that we would be missing some of the=
m again when PHP 9 comes around.
(and this is ignoring the fact that PHP does not follow semver, and I'm sta=
rting to really believe that any "semver-like" versioning system just does =
not work for a PL, especially not one like PHP which has an insanely vast A=
PI surface.)
Moreover, changing a silent error condition to throwing a ValueError on a p=
rogramming error that really never should be happening in the first place i=
s not a disruptive BC break IMHO.

And I will be repeating what I've been saying again and again, none of thes=
e issues would exist if bundled extensions did not exist.
The fact that these extensions are tied to the "core PHP language" release =
cadence is.... incredibly annoying for everyone, from maintainers to users.
Taking the example of ext/pcntl again, if it were a standalone extension, h=
aving it follow semver is a way more reasonable proposition.
Because we could just release 2 versions the same day, a x.y+1.0 introducin=
g a warning, and a x+1.0.0 which would convert them into proper errors.
Meaning as a user, you could be running whatever PHP version and have the s=
tricter behaviour, or upgrade PHP while still holding the ext/pcntl version=
 behind while you deal with the issues.

(Bonus points, the issue where PIE is currently unable to install bundled e=
xtension [1] would be solved with unbundling too.)

Best regards,

Gina P. Banyard

[1] https://github.com/php/pie/issues/133