Hi! > Technically, the internal API as it stands *can* return FAILURE > already, though I can see your argument that a caller might assume > that it'll never fail so long as they pass a string with a valid base. > I don't think I agree with your point, as it's reasonable to expect an > API caller to examine the return code of the function they're > calling,. but I can see where you're coming from.
The problem is that if we return false, and the caller expects a number, it may use the zval as numeric zval without conversion. I am not sure in 7.x using false as IS_LONG without conversion is safe anymore, but it is possible that with proper initialization it would be. Other scenarios - such as throwing without initializing the zval - may behave even worse. Option C is relatively safe I think. Maybe B is safe too, and D can be made safe with proper initialization - in any case that needs to be checked. > it's reasonable to expect an API caller to examine the return code of the function they're > calling We aren't really good in documenting when API functions return SUCCESS/FAILURE. In this particular case, the source indicates that if you send it a string and the base is constant (common case), it would never return FAILURE. So it's hard to blame extension writer who would not check for FAILURE. If we're changing the contract (or rather, having failed to document any explicit contract, changing the implied contract defined by the source code) we need at least to take some measures so that we don't create subtle bugs in other extensions. Fortunately, in this case it seems to be achievable. -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
