Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:105852
MIME-Version: 1.0
References: <CAF+90c98bNMCgKLpTVpefyarJNb_KF0WLFbuC1cR9dhpdk_qZQ@mail.gmail.com>
 <CAL0xaBHhshL+8rFRUerXz4dsKye71TzevZjjdOpMMGFWEJoRrA@mail.gmail.com>
In-Reply-To: <CAL0xaBHhshL+8rFRUerXz4dsKye71TzevZjjdOpMMGFWEJoRrA@mail.gmail.com>
Date: Thu, 6 Jun 2019 13:46:09 +0100
Message-ID: <CALKiJKoSkXZh==oUn=PHeSebPighHavdeDPKkcBu=b=knbPb3g@mail.gmail.com>
To: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000cfc79e058aa71945"
Subject: Re: [PHP-DEV] Handling of null arguments to internal functions
From: rowan.collins@gmail.com (Rowan Collins)

--000000000000cfc79e058aa71945
Content-Type: text/plain; charset="UTF-8"

On Thu, 6 Jun 2019 at 12:49, Arvids Godjuks <arvids.godjuks@gmail.com>
wrote:

> consistency, in general, would be a nice change of pace so you don't have
> to keep in mind that there are slight differences in behaviour depending on
> what you call - a built-in function or a userland one.
>


This is my view as well. Another thing that inconsistency causes problems
with is polyfills - if you want to wrap, emulate, or otherwise reimplement
an internal function, it can be fiddly to emulate the subtleties of ZPP.
(This gets worse with objects, which can do all sorts of wacky things
internally that have no user-space equivalent, but that's a topic for
another day.)

Would it be possible to use a combination of automation (analysis of the C
code, or fuzz testing of the functions) and collaboration (a great big list
people can work through a section of and report back) to categorise the
functions in core?

Something like:
a) not affected, because handling is consistent with userland anyway
b) should explicitly accept nulls
c) should explicitly reject nulls

We do however have to make a tricky judgement on functions in category c,
of how much code is going to break if we make them stricter.

Regards,
-- 
Rowan Collins
[IMSoP]

--000000000000cfc79e058aa71945--