10

I am running PHP 7.0.8 (VC14 x64 Thread Safe version) on Windows 7.

echo PHP_INT_MAX; shows 9223372036854775807, but this doesn't actually seem to be correct. According to the PHP documentation,

If PHP encounters a number beyond the bounds of the integer type, it will be interpreted as a float instead.

but when I run the code from the documentation that demonstrates integer overflow on a 32-bit system, that's not what happens.

$large_number = 2147483647;
var_dump($large_number);     // expected: int(2147483647)     actual: int (2147483647)

$large_number = 2147483648;
var_dump($large_number);     // expected: float(2147483648)   actual: int (-2147483648)

Even more strangely, the other example from the docs:

$large_number = 9223372036854775807;
var_dump($large_number);    // expected: int(9223372036854775807)    actual: int(-1)

$large_number = 9223372036854775808;
var_dump($large_number);    
    // expected: float(9.2233720368548E+18), actual: float(9.2233720368548E+18)

Is this a bug, or am I misunderstanding something? The only similar bug I've found deals with incorrect output of var_dump(PHP_INT_MAX) with xdebug (which is present in my version), but that doesn't seem to explain what's happening here. If anyone knows of relevant info I should include from phpinfo I can add it.

Don't Panic
  • 41,125
  • 10
  • 61
  • 80
  • Works here: http://sandbox.onlinephpfunctions.com/code/1a70f7c03a93c05b6583752695cacf72da7e3672 – Barmar Aug 19 '16 at 00:13
  • @Barmar yeah, I think it's something specific to my system, but I'm not sure how to go about troubleshooting it. From what I've read, PHP on windows only started supporting 64 bit ints in PHP 7, but it appears here that my version _"thinks"_ it does while it actually doesn't. – Don't Panic Aug 19 '16 at 00:16
  • 3
    Was able to reproduce your results on my Windows 7 machine. I installed Wamp (wampserver3.0.4_x64_apache2.4.18_mysql5.7.11_php5.6.19-7.0.4), switched it over to php7.0.4, and ran your code in a script. Didn't change any configuration options and i got your actual results. However, WAMP came with xdebug installed by default (awesome!). I added `xdebug.overload_var_dump=0` to my configuration, i got the expected output. If you don't have xdebug then, this comment is irrelevant. –  Aug 19 '16 at 02:11
  • @Terminus Thanks for the verification! `xdebug.overload_var_dump=0` fixes it for me as well. I think I was confused by the description in that bug report. – Don't Panic Aug 19 '16 at 12:50

1 Answers1

5

After a helpful comment from @Terminus, I tried setting xdebug.overload_var_dump=0 in php.ini. With that setting, var_dump produced the correct output. It occurred to me that I had neglected to try simply echo $large_number; during my testing, so I turned overload_var_dump back on and echo produced the expected result while var_dump did not.

$large_number = 2147483648;
echo $large_number;                // 2147483648
var_dump($large_number);           // int -2147483648

$large_number = 9223372036854775807;
echo $large_number;                // 9223372036854775807
var_dump($large_number);           // int -1

So it seems that the bug report I found earlier actually does explain this. The original description in the bug report says:

var_dump() doesn't show correct info about PHP_INT_MAX and PHP_INT_MIN constants on 64bit Windows

But it appears that this is incomplete; it actually shows incorrect info for large number variables as well as the constants.

Don't Panic
  • 41,125
  • 10
  • 61
  • 80