Description:
------------
PHP does not process hexadecimal strings in a consistent manner or
document when a hexadecimal string is evaluated as a numeric value and 
when it's not.

Whilst developing new PHPT testcase colleagues of mine have noticed
that PHP does not process hexadecimal strings in a consistent manner 
which makes it more difficult to determine what its expected and what 
is unexpected behaviour.

We have reviewed the documentation in the PHP manual on the subject at
http://www.php.net/manual/en/language.types.string.php and there is no
explicit mention here of support for hexadecimal strings but it does
contain the reference

   "For more information on this conversion, see the Unix manual page for strtod(3). "

The MSDN description of strtod makes no reference to treatment of hexadecimal strings but the Linux manual does. 

The following simple testcase demonstrates the inconsistency we are 
seeing and is based on a  testcase in a comment by "wilkinson98 at
hotmail dot com" on the manual back in 2005.

If we add to hexadecimal strings together the  strings are first 
converted to numbers by calling zendi_convert_scalar_to_number() which
calls  zend_bool is_numeric_string() to convert the strings which in 
turn calls the CRT function strtol() to do the conversion. In this 
case strtol() is called with a base of 10 or 16 dependent on whether 
or not the string starts with "0x" 

i.e the code in zend_bool is_numeric_string() reads:

    /* handle hex numbers */
    if (length>=2 && str[0]=='0' && (str[1]=='x' || str[1]=='X')) {
            conv_base=16;
    }
    errno=0;
    local_lval = strtol(str, &end_ptr_long, conv_base);

So hexadecimal strings are evaluated as numerical values and the 
addition produces the expected result. Or at least it does provided 
the string does not start with any white space, e.g "   0x123". Any white space causes a string to evaluate to 0 which again is not what 
is suggested should happen from reading the description of strtod as suggested by the PHP manual;  strtod description says white is ignored. So that needs clarifying too.

If we first cast the strings to "int" before adding them however, the
cast opcode handler calls convert_to_long()which calls convert_to_long_base() with a base of 10 which in turn calls strtol()
with base 10. As a result the hexadecimal strings both evaluate to 0 
and the result is 0.  The convert_to_long() function could easily be 
changed to employ similar logic to above to set the base dependent on 
the first 2 characters of the string but as convert_to_long() is called by a number of extension functions to convert 
passed arguments, e.g range() this means that these functions will 
also have their behaviour changed too. Whilst this would be good form the point of view of consistency it may break existing applications. 

PHP either needs to be changed to either consistently evaluate hexadecimal strings as numerical values when appropriate (and I 
believe casting a string to an int is a case where an hexadecimal
string should be evaluated as numerical value) or document clearly 
when a hexadecimal string will be evaluated as a numeric value and 
when it's not. 

I am raising this defect to flag the issue and get feed back on whether the code or manual should be fixed here. I would prefer to see
the code fixed but accept that doing so may break existing applications and so all that can be done is to document the behaviour.
Either way I am happy to work with my colleagues developing the new PHPT testcases to determine which code or manual pages need fixing.


Reproduce code:
---------------
<?php

$a = "0x32";
$b = "0x64";

echo $a + $b, "\n";
echo (int)$a + (int)$b, "\n";

?>

Expected result:
----------------
150
150

Actual result:
--------------
150
0