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 "
}

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.

Jani, as you can tell from my explanation, -1e99 becomes 0 with 5.2, but LONG_MIN with 5.3/6. In the explode() function, there is/was a int/long mismatch, so overflow issues on 64-bit, causing an unexpected value of "limit" in php_explode_negative_limit() and, I'm guessing, an invalid read of "positions" there.

I fixed the long/int mismatch in 5.3/6 a couple weeks ago, so I assume the strange results are gone? BTW, since 5.2 isn't using long where needed, you should be able to break it (on 64-bit) by passing -PHP_INT_MAX - 1 instead of -1e99.

Closed then, eh?