clones/php-src
1
0
Fork 0
mirror of https://github.com/php/php-src.git synced 2024-09-21 18:07:23 +00:00
Code Issues Packages Projects Releases Wiki Activity
b9e1ea33b9
php-src/Zend/tests/dval_to_lval_32.phpt

33 lines
663 B
Plaintext
Raw Normal View History

Fix zend_dval_to_lval outside 64bit integers range PHP should preserve the least significant bits when casting from double to long. Zend.m4 contains this: AC_DEFINE([ZEND_DVAL_TO_LVAL_CAST_OK], 1, [Define if double cast to long preserves least significant bits]) If ZEND_DVAL_TO_LVAL_CAST_OK is not defined, zend_operators.h had an inline implementation of zend_dval_to_lval() that would do a cast to an int64_t (when sizeof(long) == 4), then a cast to unsigned long and finally the cast to long. While this works well for doubles inside the range of values of the type used in the first cast (int64_t in the 32-bit version and unsigned long in the 64-bit version), if outside the range, it is undefined behavior that WILL give varying and not particularly useful results. This commit uses fmod() to first put the double in a range that can safely be cast to unsigned long and then casts this unsigned long to long. This last cast is implementation defined, but it's very likely that this gives the expected result (i.e. the internal 2's complement representation is unchanged) on all platforms that PHP supports. In any case, the previous implementationa already had this assumption. This alternative code path is indeed significantly slower than simply casting the double (almost an order of magnitude), but that should not matter because casting doubles with a very high absolute value is a rare event.
2013-02-17 22:40:26 +00:00
--TEST--
zend_dval_to_lval preserves low bits (32 bit long)
--SKIPIF--
<?php
if (PHP_INT_SIZE != 4)
Run tidy This should fix most of the remaining issues with tabs and spaces being mixed in tests.
2020-09-18 12:28:32 +00:00
die("skip for machines with 32-bit longs");
Fix zend_dval_to_lval outside 64bit integers range PHP should preserve the least significant bits when casting from double to long. Zend.m4 contains this: AC_DEFINE([ZEND_DVAL_TO_LVAL_CAST_OK], 1, [Define if double cast to long preserves least significant bits]) If ZEND_DVAL_TO_LVAL_CAST_OK is not defined, zend_operators.h had an inline implementation of zend_dval_to_lval() that would do a cast to an int64_t (when sizeof(long) == 4), then a cast to unsigned long and finally the cast to long. While this works well for doubles inside the range of values of the type used in the first cast (int64_t in the 32-bit version and unsigned long in the 64-bit version), if outside the range, it is undefined behavior that WILL give varying and not particularly useful results. This commit uses fmod() to first put the double in a range that can safely be cast to unsigned long and then casts this unsigned long to long. This last cast is implementation defined, but it's very likely that this gives the expected result (i.e. the internal 2's complement representation is unchanged) on all platforms that PHP supports. In any case, the previous implementationa already had this assumption. This alternative code path is indeed significantly slower than simply casting the double (almost an order of magnitude), but that should not matter because casting doubles with a very high absolute value is a rare event.
2013-02-17 22:40:26 +00:00
?>
--FILE--
<?php
Reindent phpt files
2020-02-03 21:52:20 +00:00
/* test doubles around -4e21 */
$values = [
-4000000000000001048576.,
-4000000000000000524288.,
-4000000000000000000000.,
-3999999999999999475712.,
-3999999999999998951424.,
];
/* see if we're rounding negative numbers right */
$values[] = -2147483649.8;
Fix zend_dval_to_lval outside 64bit integers range PHP should preserve the least significant bits when casting from double to long. Zend.m4 contains this: AC_DEFINE([ZEND_DVAL_TO_LVAL_CAST_OK], 1, [Define if double cast to long preserves least significant bits]) If ZEND_DVAL_TO_LVAL_CAST_OK is not defined, zend_operators.h had an inline implementation of zend_dval_to_lval() that would do a cast to an int64_t (when sizeof(long) == 4), then a cast to unsigned long and finally the cast to long. While this works well for doubles inside the range of values of the type used in the first cast (int64_t in the 32-bit version and unsigned long in the 64-bit version), if outside the range, it is undefined behavior that WILL give varying and not particularly useful results. This commit uses fmod() to first put the double in a range that can safely be cast to unsigned long and then casts this unsigned long to long. This last cast is implementation defined, but it's very likely that this gives the expected result (i.e. the internal 2's complement representation is unchanged) on all platforms that PHP supports. In any case, the previous implementationa already had this assumption. This alternative code path is indeed significantly slower than simply casting the double (almost an order of magnitude), but that should not matter because casting doubles with a very high absolute value is a rare event.
2013-02-17 22:40:26 +00:00
Reindent phpt files
2020-02-03 21:52:20 +00:00
foreach ($values as $v) {
var_dump((int)$v);
}
Fix zend_dval_to_lval outside 64bit integers range PHP should preserve the least significant bits when casting from double to long. Zend.m4 contains this: AC_DEFINE([ZEND_DVAL_TO_LVAL_CAST_OK], 1, [Define if double cast to long preserves least significant bits]) If ZEND_DVAL_TO_LVAL_CAST_OK is not defined, zend_operators.h had an inline implementation of zend_dval_to_lval() that would do a cast to an int64_t (when sizeof(long) == 4), then a cast to unsigned long and finally the cast to long. While this works well for doubles inside the range of values of the type used in the first cast (int64_t in the 32-bit version and unsigned long in the 64-bit version), if outside the range, it is undefined behavior that WILL give varying and not particularly useful results. This commit uses fmod() to first put the double in a range that can safely be cast to unsigned long and then casts this unsigned long to long. This last cast is implementation defined, but it's very likely that this gives the expected result (i.e. the internal 2's complement representation is unchanged) on all platforms that PHP supports. In any case, the previous implementationa already had this assumption. This alternative code path is indeed significantly slower than simply casting the double (almost an order of magnitude), but that should not matter because casting doubles with a very high absolute value is a rare event.
2013-02-17 22:40:26 +00:00
?>
--EXPECT--
int(-2056257536)
int(-2055733248)
int(-2055208960)
int(-2054684672)
int(-2054160384)
Fix rounding of zend_dval_to_lval Now rounding is always towards zero; the rounding can be though as if occurring on the original double. Only relevant for the 32-bit long variant.
2013-02-22 23:41:39 +00:00
int(2147483647)
Reference in New Issue Copy Permalink