Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:34479
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zend.com designates 212.25.124.162 as permitted sender)
Message-ID: <477E8C4C.2090808@zend.com>
Date: Fri, 04 Jan 2008 11:43:08 -0800
Organization: Zend Technologies
User-Agent: Thunderbird 2.0.0.9 (Windows/20071031)
MIME-Version: 1.0
To: Stefan Esser <stefan.esser@sektioneins.de>
CC: internals Mailing List <internals@lists.php.net>
References: <477DB7BF.10201@chiaraquartet.net> <20080104105558.GC7861@mint.phcomp.co.uk> <477E5649.2080104@chiaraquartet.net> <477E619C.2050107@sektioneins.de> <477E79AE.6050407@zend.com> <477E853E.5000308@sektioneins.de>
In-Reply-To: <477E853E.5000308@sektioneins.de>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] type hinting
From: stas@zend.com (Stanislav Malyshev)

> There is a difference in complexity between a userlevel type check and a
> low level type check.

Rather minimal.

> How should one have an optimizer for that as long PHP does not have this
> feature? Noone would implement one that is capable of doing this not
> knowing if the feature ever makes it into PHP.

There are a lot of places where you can know and/or derive types right now.

> To analyse this construct a static code analyser has a lot todo and it
> still needs to check every call to getUserFromId() to verify if this is
> an actual security hole, because it doesn't know the content of
> SOME_RUNTIME_CONSTANT and therefore the return value of decryptID could
> be a binary xored string. However a type hint of int in the decryptID()
> function would allow the analyser to know that decryptID() always return
> int and this would tell it that this is not a security hole. You see in

That provided you actually expected decryptID() to return int, which is 
not obvious at all. But even then it's not an analyser problem - 
analyzer should just tell the user he is using xor(unknown, unknown) and 
recommend to do ((integer)$id)^RUNTIME_CONSTANT.
Anyway, I do not doubt you can find special cases where this function 
could be useful. It is obvious that since you want this function you 
have some use cases for it. However, I do doubt these cases are common 
enough to make a difference - the fact that for ^ to be string both 
operands should be strings is just a peculiar property of ^, you could 
as well have a function there which could return string if only one of 
operands were string. That does not improve general case, only some very 
specific instances of some very specific cases.
-- 
Stanislav Malyshev, Zend Software Architect
stas@zend.com   http://www.zend.com/
(408)253-8829   MSN: stas@zend.com