Hi!
> On the surface, this sounds like a good thing. Although, I question that
> if a user is not checking $result === false, then will they end up just
> wrapping this in an empty try/catch so their code does not fail? There
> is a mechanism to detect the error now.
True, but not checking for false is an error of omission, and an easy
one to make ("How can random fail? It's just creating random numbers! I
won't bother to check"), while wrapping in try/catch has to be done
explicitly - and can be easily caught on review, even often with
automatic tools, and people can be trained not to do empty try/catches
(it is much easier to train for "do not do this specific thing" than
"always do these 1000 things in 1000 different special cases").
> I question why the cryptographic functions would not force an integer to
> be passed. Those should not accept a boolean and evaluate it as false. I
> am not sure what functions you are talking about though. Maybe 3rd party
> user land code? Accepting a boolean in those cases is a bug in that code
> IMO.
Given PHP is a weakly-typed language, I don't thing you can rely on this
kind of type checking. While in many cases we can tell people "just
check for errors or accept the fallout", when we come to security I
think the price is too high.
--
Stas Malyshev
smalys...@gmail.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
