ID: 47854
Updated by: matt...@php.net
Reported By: disas at mail dot ru
Status: Verified
Bug Type: Strings related
Operating System: *
PHP Version: 5.*, 6CVS (2009-04-01)
New Comment:
What's happening with -1e9 is that it's small enough to fit in the
range of an integer (which explode()'s limit parameter expects). (Other
larger numbers that aren't in the integer range may or may not behave as
expected -- if there's integer overflow/"wraparound", with -3e9 for
example, negative may become positive, or vice versa, giving different
behavior than the sign of limit would suggest.)
However, when you give a much larger number like -1e99 and it gets cast
to an integer, it actually just becomes 0 which explains the behavior
you're seeing.
Additional info that the bug reporter can ignore if they want:
That explanation applies to PHP 5.2 and prior. But in 5.3 as of right
now, on *most* platforms (except Win64), *most* numbers out of integer
range (except between 2^31 and 2^32-1 on 32-bit platforms) have a "hard
limit" applied that keeps them at the negative/positive integer limit,
so no matter how large of a number you pass to explode(), even infinity,
it ends up being the integer limit (with same sign). Like I said, this
varies by platform, but that's the general behavior in 5.3 right now.
Overall, 5.3's conversion of large floats is currently inconsistent,
flawed, and changes prior behavior that's been around for years, which
is why I'm trying to get it sorted out. Now in cases like this, with
function parameters like a "limit," the new behavior makes sense (which
only happens in *most* cases, thanks to platform inconsistencies).
But wait, it gets better: Don't pass the parameter as a number, but as
a string, e.g. '-1e99', and you'll probably get a different result
still! Again, depending on platform -- absolute difference between
platforms and/or relative difference compared to a non-string version.
What a mess... And this applies to basically every function in 5.3 that
takes an integer parameter. My proposed changes take care of these
things and allow functions, like explode(), to use a new integer
conversion specifier, where desired, to limit a parameter to the range
of an integer *consistently*. Functions that aren't updated would simply
behave like 5.2 and prior.
Previous Comments:
------------------------------------------------------------------------
[2009-04-01 11:00:26] j...@php.net
Very strange results with HEAD/PHP_5_3 too:
# build/php_6/sapi/cli/php -n -dmemory_limit=2G -r
'var_dump(explode(" "," 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 ",
-1e99));'
Fatal error: Allowed memory size of 2147483648 bytes exhausted (tried
to allocate 18446744073383068122 bytes) in Command line code on line
1
# build/php_5_3/sapi/cli/php -n -dmemory_limit=2G -r
'var_dump(explode(" "," 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 ",
-1e99));'
Fatal error: Allowed memory size of 2147483648 bytes exhausted (tried
to allocate 3792765909 bytes) in Command line code on line 1
# build/php_5_2/sapi/cli/php -n -dmemory_limit=2G -r
'var_dump(explode(" "," 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 ",
-1e99));'
array(1) {
[0]=>
string(43) " 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 "
}
------------------------------------------------------------------------
[2009-03-31 19:15:47] disas at mail dot ru
Description:
------------
Bug on result where negative or positive number of limit is very high.
Reproduce code:
---------------
#Code:
var_export(
explode(" "," 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 ", -1e99)
);
#Result:
array (
0 => ' 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 ',
);
#Code:
var_export(
explode(" "," 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 ", -1e9)
);
#Result:
array (
)
Expected result:
----------------
array (
0 => ' 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 ',
);
Actual result:
--------------
I think that in both cases the result should be:
array(
)
------------------------------------------------------------------------
--
Edit this bug report at http://bugs.php.net/?id=47854&edit=1
