Bug #54973 [Com]: SimpleXML casts intergers wrong.

From: Date: Wed, 06 Nov 2013 14:42:24 +0000
Subject: Bug #54973 [Com]: SimpleXML casts intergers wrong.
References: 1  Groups: php.bugs 
Request: Send a blank email to php-bugs+get-182616@lists.php.net to get a copy of this message
Edit report at https://bugs.php.net/bug.php?id=54973&edit=1 ID: 54973 Comment by: corry at jhstudios dot com Reported by: bphelpsen at gmail dot com Summary: SimpleXML casts intergers wrong. Status: Analyzed Type: Bug Package: SimpleXML related Operating System: Linux PHP Version: 5.3.6 Block user comment: N Private report: N New Comment: $stdobj= new stdClass; $stdobj->Price='.53'; echo 1+$stdobj->Price; output: object(stdClass)#1 (1) { ["Price"]=> string(3) ".53" } 1.53 This shows that the standard class is correctly juggled from a string to a float when added to an integer. This is in contrast to other comments that suggested that the reported behavior is to be expected. Previous Comments: ------------------------------------------------------------------------ [2013-07-22 08:33:16] kaplan@php.net The referenced pull request (#213) has two tests to verify the fix for this bug (when and if ready). Please don't forget to use them when commiting the fix. ------------------------------------------------------------------------ [2011-06-03 11:55:06] cataphract@php.net I remember seeing this before. The problem is that the Zend engine, when doing the add operation, converts any objects it finds to ints. The simplexml extension is merely doing what it's asked, i.e., convert the value of the object to int. The solution must be either a) making the Zend Engine default the conversion to a double b) making the Zend Engine try both a double and an int and compare the two results c) making the Zend Engine convert the object to a string instead and then convert the string using the usual means (that is, is_numeric_string) d) change the API so that cast_object can be told to convert the object to either an int or a double, sort of like is_numeric_string ------------------------------------------------------------------------ [2011-06-02 22:14:14] dtajchreber@php.net This looks like a bug... SimpleXML's cast_object handler doesn't check for overflow when trying to convert a node value to a long. $xml->value goes through Zend's add_function and gets passed to zendi_convert_scalar_to_number which calls SimpleXML's cast_object handler because $xml->number is an object. It then gets chopped into LONG_MAX by strtol. An overflow check could fix this... but it might break some BC.... [1] http://lxr.php.net/xref/PHP_5_3/Zend/zend_operators.c#758 [2] http://lxr.php.net/xref/PHP_5_3/ext/simplexml/simplexml.c#1722 [3] http://lxr.php.net/xref/PHP_5_3/Zend/zend_operators.c#355 [4] http://lxr.php.net/xref/PHP_5_3/Zend/zend_operators.c#768 [5] http://www.gnu.org/s/hello/manual/libc/Parsing-of-Integers.html ------------------------------------------------------------------------ [2011-06-02 20:05:07] bphelpsen at gmail dot com Then why do I get different results when I run this code: <?php echo "214748364800" / 1024 / 1024 / 1024; ?> than when I run the example code. Shouldn't they return the same value? Here is an example, with the same results as my local test: http://codepad.org/KICl3xHw ------------------------------------------------------------------------ [2011-06-02 20:00:54] iliaa@php.net Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php This has nothing to do with SimpleXML, but rather the fact that a numeric string in PHP by default would converted to an integer. ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=54973 -- Edit this bug report at https://bugs.php.net/bug.php?id=54973&edit=1

« previous php.bugs (#182616) next »