Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:127447
Feedback-ID: ifab94697:Fastmail
Precedence: bulk
MIME-Version: 1.0
Date: Sat, 24 May 2025 21:24:24 +0200
To: internals@lists.php.net
Message-ID: <db784868-187d-42ff-9575-64b5ca70f50b@app.fastmail.com>
In-Reply-To: <8b76a3d4-4583-4849-a75f-00f645191247@gmail.com>
References: <bc1ec15125844c78a6aa23dce6148af9@danielkesselberg.de>
 <8b76a3d4-4583-4849-a75f-00f645191247@gmail.com>
Subject: Re: [PHP-DEV] [RFC] Add num_available_processors
Content-Type: multipart/alternative;
 boundary=b91e5aded8664fdf801c08c8a7eb1f61
From: rob@bottled.codes ("Rob Landers")

--b91e5aded8664fdf801c08c8a7eb1f61
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable



On Sat, May 24, 2025, at 19:42, Niels Dossche wrote:
> Hi
>=20
> In my opinion, the return type should not be nullable.
> Returning NULL when the platform (or PHP on that platform) doesn't sup=
port getting this information is an anti-pattern.
> Instead, availability of the necessary functionality should be checked=
 at configure time and the function should be made conditionally availab=
le.
> That way, the return type can just be "int".
>=20
> Kind regards
> Niels
>=20

I=E2=80=99m curious why you say this is an =E2=80=9Canti pattern=E2=80=9D=
? I do agree that it should return a number or throw. There are various =
error conditions it should throw (at least on Linux) so having it throw =
an exception when there isn=E2=80=99t a way to count any processors make=
s more sense than returning null.

I also note the patch is using the sysconf method and not checking the e=
rror on a negative one result and not properly handling zero. Naturally,=
 this means something might be catastrophically wrong, but it should sti=
ll throw instead of returning null. It could also be someone patching li=
bc to get around per-core licensing too. I=E2=80=99ve seen the latter mo=
re often than the former.=20

=E2=80=94 Rob
--b91e5aded8664fdf801c08c8a7eb1f61
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE html><html><head><title></title></head><body><div><br></div><d=
iv><br></div><div>On Sat, May 24, 2025, at 19:42, Niels Dossche wrote:</=
div><blockquote type=3D"cite" id=3D"qt" style=3D""><div>Hi</div><div><br=
></div><div>In my opinion, the return type should not be nullable.</div>=
<div>Returning NULL when the platform (or PHP on that platform) doesn't =
support getting this information is an anti-pattern.</div><div>Instead, =
availability of the necessary functionality should be checked at configu=
re time and the function should be made conditionally available.</div><d=
iv>That way, the return type can just be "int".</div><div><br></div><div=
>Kind regards</div><div>Niels</div><div><br></div></blockquote><div><br>=
</div><div>I=E2=80=99m curious why you say this is an =E2=80=9Canti patt=
ern=E2=80=9D? I do agree that it should return a number or throw. There =
are various error conditions it should throw (at least on Linux) so havi=
ng it throw an exception when there isn=E2=80=99t a way to count any pro=
cessors makes more sense than returning null.</div><div><br></div><div>I=
 also note the patch is using the sysconf method and not checking the er=
ror on a negative one result and not properly handling zero. Naturally, =
this means something might be catastrophically wrong, but it should stil=
l throw instead of returning null. It could also be someone patching lib=
c to get around per-core licensing too. I=E2=80=99ve seen the latter mor=
e often than the former.&nbsp;<br></div><div><br></div><div id=3D"sig121=
229152">=E2=80=94 Rob</div></body></html>
--b91e5aded8664fdf801c08c8a7eb1f61--