On Mon, 16 Mar 2015, Yasuo Ohgaki wrote:

> On Mon, Mar 16, 2015 at 5:17 PM, Pierre Joye <pierre....@gmail.com> wrote:
> 
> > On Mar 16, 2015 6:46 PM, "Yasuo Ohgaki" <yohg...@ohgaki.net> wrote:
> > >
> > > On Mon, Mar 16, 2015 at 3:33 PM, Dennis Birkholz <den...@birkholz.biz>
> > > wrote:
> > >
> > > > Am 16.03.2015 um 07:22 schrieb Yasuo Ohgaki:
> > > >
> > > > > Caller _must_ satisfy callee requirements. This is simple 
> > > > > principle to write a secure code.
> > > > >
> > > > > With this RFC, caller overrides security related setting. This 
> > > > > means scripts that are prepared for type safety is "ignored" 
> > > > > and it leads security breach.

That's not true. The caller does not override any security setting. The 
receiving function (callee) will *always* get the type they declared. 
*That* is important for security.

When I first saw Andrea's v3, I was also of the opinion that it should 
be the callee that controls whether the type hints should be strict or 
not. But then I realized that it *does not matter*, as the callee will 
get the right type regardless. Allowing the caller to decide whether it 
throws an error or not, is irrelevant to any sort of security. Realizing 
that it didn't matter, made me change my "no" vote to "yes".

> I thought majority of us see the benefit of StrictSTH over this RFC. 
> You're right about it.
> 
> This RFC will have serious consequence. We made mistake with 
> "safe_mode". The main reason it failed is "it did not force caller to 
> have responsibility to make it work as it should". This RFC does the 
> same for how declare(strict_types=1) works.
> 
> Aren't we learned from "safe_mode" lessons?

I am not sure why you mention "safe_mode" as this has absolutely nothing 
to do with scalar type hints. Not feature wise, not implementation wise.

safe_mode, first of all, was a global INI setting. The developer 
couldn't turn it off easily. That was probably at least 80% of the pain. 
The second part was the name, as it indicated that it made your scripts 
safe: It didn't.

STHv5 does not suffer from either issue — developers can pick and choose 
the best solution for *them* (give them some credit, most developers are 
actually smart!). Library authors always get the right type if they type 
hint, which is *their* main pain point. And the type names have always 
already been used for casts anyway, and don't include "safe" in their 
name.

cheers,
Derick
-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to