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
>
> On 07/26/2015 01:36 PM, Jakub Kubíček 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 === 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 = 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 !== $pos = 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".
>
> Yes, I am referring to the second, or variations therein. When using
> strpos() you need to do a strict check against FALSE (===) 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.
>
> 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 === 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.
>
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.
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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
> -----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
>
> On 07/26/2015 01:36 PM, Jakub Kubíček 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 === 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 = 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 !== $pos = 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".
>
> Yes, I am referring to the second, or variations therein. When using
> strpos() you need to do a strict check against FALSE (===) 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.
>
> 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 === 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.
>
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.
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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php