Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:87304
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain belski.net from 85.214.73.107 cause and error)
To: "'Larry Garfield'" <larry@garfieldtech.com>,
	<internals@lists.php.net>
References: <CALYT1Yo-ae+cemXaaXs5Jv5t2DSzdxdYuxuhEGbXyoo_863+bw@mail.gmail.com> <55A7D993.5000301@moonspot.net> <55B2D142.6020802@gmail.com> <55B41BEC.20104@garfieldtech.com> <CAHvhOfi4N+enTEh32iNBfqyStYxtZ0obDMLBapXBOjvZ9CcJGw@mail.gmail.com> <55B53731.8030203@garfieldtech.com>
In-Reply-To: <55B53731.8030203@garfieldtech.com>
Date: Sun, 26 Jul 2015 22:05:02 +0200
Message-ID: <057301d0c7de$5da5d2c0$18f17840$@belski.net>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Thread-Index: AQDrJ9+0MU8FOQ/rKelUCzkNPL+2ggK6CMLOAtMV3G0B7ALmQwIhjEK+AkoanrqfWkEGEA==
Content-Language: en-us
Subject: RE: [PHP-DEV] Core functions throwing exceptions in PHP7
From: anatol.php@belski.net ("Anatol Belski")

Hi,

> -----Original Message-----
> From: Larry Garfield [mailto:larry@garfieldtech.com]
> Sent: Sunday, July 26, 2015 9:38 PM
> To: internals@lists.php.net
> Subject: Re: [PHP-DEV] Core functions throwing exceptions in PHP7
>=20
> On 07/26/2015 01:36 PM, Jakub Kub=C3=AD=C4=8Dek wrote:
> > Hi Larry!
> >
> > 2015-07-26 1:29 GMT+02:00 Larry Garfield <larry@garfieldtech.com>:
> >> Another point here is that 0 is a perfectly legitimate random =
number
> >> in many cases, so callers would need to do a =3D=3D=3D check, not =
just a boolean
> check.
> > What "boolean check" are you talkin' about? I've never seen a code
> > using e.g. strpos() like follows:
> >
> > <?php
> >
> > if(!is_bool($pos =3D strpos('foobar', 'baz'))) {
> >      // we are correct, use $pos' value somewhere } else {
> >      // strpos() produced a boolean, thus no 'baz' found in 'foobar'
> > }
> >
> > ?>
> >
> > Rather it is most frequently being done like below:
> >
> > <?php
> >
> > if(FALSE !=3D=3D $pos =3D strpos('foobar', 'baz')) {
> >      // we are correct, use $pos' value somewhere } else {
> >      // strpos() produced a boolean, thus no 'baz' found in 'foobar'
> > }
> >
> > ?>
> >
> > I think in both cases you do a kind of "boolean check".
>=20
> Yes, I am referring to the second, or variations therein.  When using
> strpos() you need to do a strict check against FALSE (=3D=3D=3D) to =
avoid a legit 0
> getting misinterpreted.  It's also a very commonly forgotten check, =
especially
> among newer devs that haven't been burned by it a few times.
>=20
> My point is that when talking about crypto-related functions, relying =
on people
> to get burned a few times and then remember to do a =3D=3D=3D check =
against FALSE is
> a horrible, horrible idea, hence random_int() should fail much harder, =
as is being
> suggested here (be that via E_FATAL, exception, error throw, or =
whatever, as
> long as the execution does NOT continue).  That is, I am agreeing with =
the
> proposal to have it die hard.  I moderately prefer the throw =
SecurityError
> approach as it's not a user-input error but a system config error, but =
anything
> that prevents execution from continuing is acceptable security-wise.
>=20
When implementing a security related code, people that are tired or =
asleep should stay home :) But going seriously - what it is about is =
changing the paradigm. IMHO this kind of thing should not be done making =
a special case. Since Trowable is a good base, there is a need on a =
strategy.=20

The keyword about the "exception hierarchy" is not seldom to hear it =
this regard nowadays. So besides SecurityError, what is with IOError, =
MemoryError, other common cases? Also be aware and prepared that many =
cases can't currently be served by exceptions, the very low level  =
errors. But basically what I would refer to is a concept catching the =
common cases, so then

- we have a set of rules about exceptions in functions
- those rules produce consistent behaviors
- the "case by case basis" argument is eliminated by them in 99% of =
cases

Regards

Anatol