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 [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
