Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:88209
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain thesba.com designates 208.106.205.211 as permitted sender)
To: Stanislav Malyshev <smalyshev@gmail.com>
CC: internals <internals@lists.php.net>
Thread-Topic: [PHP-DEV] PHP 7.1 - Address PHPSadness #28?
Thread-Index: AQHQ36zP6Wb5e1HnokKnJlazAkejtZ4eJ62AgABxe4CAAAPLgIAAJlKAgAAUa4CAACGZAIAAGymAgAjS3QCAAJOjgIAA+D+AgAA5fACAB+afgIAB6WsAgAFo8ICAACyWAIAHac+AgAAGeYCAAD+qgIAAAnkAgABF9ACAAAG1gIAAJ92AgAAFuoCAADs0MA==
Date: Tue, 15 Sep 2015 09:38:08 +0000
Message-ID: <D062C4F7-B56E-422F-A563-C7C4A16D36B0@thesba.com>
References: <CAKws9z27kVJ87Ur5Qo+ayYHPeeO=aYKpRHUV4TFBXX2iMcgO2A@mail.gmail.com>
 <55DDA4C9.9040603@gmail.com>
 <3C69BF4B-52E6-4D04-8601-8D23DFCC538E@craigfrancis.co.uk>
 <55DDD60F.5090509@gmail.com>
 <8C74463E-DBA2-4015-8159-0B44D973387F@craigfrancis.co.uk>
 <55DE0907.6040904@gmail.com>
 <1F615BCD-1B9B-4C51-A210-869F1AA1F6E3@craigfrancis.co.uk>
 <55E5EBBF.6020803@gmail.com>
 <0BA3A129-D356-4781-B6DE-E2B5A7924AE2@craigfrancis.co.uk>
 <55E6EC36.6090301@gmail.com>
 <E1C02A1A-EB7C-40D9-8760-13627CC7BF85@craigfrancis.co.uk>
 <9AF329EC-99A5-412D-A52B-432627A5520F@gmail.com>
 <6F4D91EE-B56E-4B83-B1AF-598C3F6897FC@craigfrancis.co.uk>
 <55F07BA4.2000204@gmail.com>
 <E8634CF1-C2B4-4C5A-8DDC-531D9599774B@craigfrancis.co.uk>
 <55F6B911.9080400@gmail.com>
 <96BE7F01-D04B-483B-B1A3-B45CED6DFCDC@craigfrancis.co.uk>
 <55F6F08C.1020506@gmail.com>
 <0BEF6D82-CB5F-49F6-A3A4-3267924A0CDA@thesba.com>
 <55F72CA9.2060301@gmail.com>
 <09369945-76FE-4E08-9C2C-15FB0577AD27@thesba.com>,<55F752E7.9070801@gmail.com>
In-Reply-To: <55F752E7.9070801@gmail.com>
Accept-Language: en-US
Content-Language: en-US
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [PHP-DEV] PHP 7.1 - Address PHPSadness #28?
From: rewilliams@thesba.com (Robert Williams)

On Sep 14, 2015, at 16:06, Stanislav Malyshev <smalyshev@gmail.com> wrote:
>=20
>>> No. There's no reason for null to exist if isset returns true on=20
>>> null. If one doesn't understand that, one should not be using
>>> null at all.
>>=20
>> Nonsense.
>=20
> Oh, thank you! That's a good start for a polite argument.

Apologies, no offense intended, but you do realize that you essentially sai=
d that any programmer who doesn't agree with what you profess is the One Tr=
ue Way, is doing it wrong? This type of statement has been made several tim=
es in this thread, and it's annoyingly dismissive. Given how PHP has evolve=
d, and how many architectural inconsistencies there are, I'm not so sure th=
ere is a One True Way.

>> It just means that one isn=92t using null the way you do.
>=20
> No, it means one isn't using null the way it is intended to be used in
> the language.

It really seems to me that PHP is fundamentally confused in how it wants to=
 treat null. It clearly has the concept of an undefined variable: variable =
existence is referenced throughout the docs along with null-ness (e.g., the=
 docs for isset() say it returns true if the variable, "is set and is not n=
ull" and if the variable, "exists and has value other than null"), it throw=
s undefined errors for using variables that aren't defined, and it even has=
 an unset() construct that leads to an undefined variable that fails isset(=
). Yet, it also defines undefined variables as being null -- which is it? E=
ven is_null() is caught up in this: it will throw an undefined error if pas=
sed an undefined variable while also returning true. Why an error for a val=
ue that supposedly fits the definition of null?

>> functions do. As I said, they=92re misguided, right up there with=20
>> register_globals. (They lead to similar security bugs, too.)
>=20
> Please do not bring "security" as some superman-argument, expecting
> that is you say "security" your arguments suddenly become so much
> stronger. There's no special security problem here besides the trivial
> fact that if you write buggy code in security-sensitive context, you
> get security issue. So please leave security out of it.

Re-read what I said. I didn't say any of this was a security bug. I said it=
 can lead to security bugs. And that is, I think, undeniably true because n=
ull handling in PHP is clearly confusing to a lot of folks, and any confusi=
ng API (buggy or not) will tend to lead to application-level security bugs =
if that API is often used in security contexts. Hasn't a bunch of work rece=
ntly been completed with hashing and encryption APIs for this very reason? =
Same idea.

I also mentioned the security issue parenthetically, as a side-note, so ple=
ase don't accuse me of overplaying the security card. My main point there w=
as that isset() and empty() were ill-conceived.

And again, who's doing the bashing here? Ease off a bit -- I'm really not t=
rying to attack you at all.=20

>> If a variable that=92s declared yet defined as null can=92t =93exist=94 =
as=20
>> decided by isset(), why can an array element that=92s declared yet=20
>> defined as null =93exist=94 as decided by array_key_exists()? Is the
>=20
> Because these are two different functions doing different things.
> That's like asking why strlen returns string length but fopen does not
> return file length.

Clearly, they're different functions, but I think they're doing something d=
ifferent only so far as they operate in different contexts. Their purposes =
are closely related, IMHO, which is why they keep being paired together in =
this thread and why people keep using one when they should be using the oth=
er. If we allow that, then it would make sense for them to function similar=
ly.

Okay, so to bring this home:

1 PHP defines null to include variables that have "not been set"
2 PHP also defines null to include variables that have been unset()
3 Variables can be explicitly set to null

All of these are null. And yet:

4 Calling isset(), which is documented to return true on null, on 1, 2, and=
 3 will only return true for 3.

How's this consistent?

Returning true on 1 and 2 suggests clearly that PHP does distinguish betwee=
n undefined variables and null variables. This supposition is also supporte=
d by numerous mentions of these concepts in the docs and by the various und=
efined error messages that PHP produces. It goes off the tracks, however, w=
hen it returns true for 3.

IMHO, PHP went south in its design when it tried to declare undefined varia=
bles as null. They're not; they're undefined. Beyond isset/empty/is_null, h=
owever, the rest of PHP seems to accept this. Even the three deviant functi=
ons tacitly acknowledge the issue in their documentation, e.g. with isset()=
's existence requirement as part of a compound statement ("exists and has v=
alue other than null"). PHP falls short, however, in not providing a way to=
 independently test each part of that compound statement.

Ideally, we would reverse course on the undefined-is-null declaration then =
adjust isset/empty/is_null accordingly, but I realize that opens a large ca=
n of worms. Providing a simple exists() function doesn't solve the root iss=
ue, but it at least gives a way to directly test for a very real condition:=
 the first half of the isset() compound requirements statement. If we can d=
o that, we will have what we need to mostly regard the null design error as=
 an academic matter with relatively little real-world consequence going for=
ward.


Regards,
Bob