ID: 49974 User updated by: admin at saltwaterc dot net -Summary: Windows x64 build lacks proper suport for 64-bit signed long Reported By: admin at saltwaterc dot net Status: Assigned Bug Type: Scripting Engine problem Operating System: win32 only - Windows x64 PHP Version: 5.2.11 Assigned To: pajoye New Comment:
Well, even though 5.2 doesn't have support - it does compile. The task manager shows the runtime as native 64-bit app. The assertion test was the whole idea: assertion failed. In unit testing, the assertions should not fail in order to pass the test. I simply changed 2147483647 with 3147483647 (the first digit) in order to make it to fail a test that should not fail under x64, but fails under x86. It could have been 314748364700000 which I assure you that its 32-bit float representation won't pass as integer, but under 64-bit is fine. Under Windows, yes, it displays your output for PHP_INT_MAX with either a x86 build or a x64 build. I know what's the upper limit for 32-bit signed long, where under 64-bit the PHP integer should be a signed long long. Under Debian/Ubuntu/Linux, the 5.2.x x86_64 builds: (Ubuntu Hardy) rem...@ubuntuvz:~$ php -r 'echo PHP_INT_MAX."\n";' 9223372036854775807 rem...@ubuntuvz:~$ php -v PHP 5.2.4-2ubuntu5.7 with Suhosin-Patch 0.9.6.2 (cli) (built: Aug 21 2009 22:17:39) Copyright (c) 1997-2007 The PHP Group Zend Engine v2.2.0, Copyright (c) 1998-2007 Zend Technologies rem...@ubuntuvz:~$ php long.php rem...@ubuntuvz:~$ # no failure here (Debian Lenny) saltwa...@web:~$ php -r 'echo PHP_INT_MAX."\n";' 9223372036854775807 saltwa...@web:~$ php -v PHP 5.2.6-1+lenny3 with Suhosin-Patch 0.9.6.2 (cli) (built: Apr 26 2009 20:09:03) Copyright (c) 1997-2008 The PHP Group Zend Engine v2.2.0, Copyright (c) 1998-2008 Zend Technologies with Xdebug v2.0.3, Copyright (c) 2002-2007, by Derick Rethans with Suhosin v0.9.27, Copyright (c) 2007, by SektionEins GmbH saltwa...@web:~$ php long.php saltwa...@web:~$ # no failure here either (Ubuntu Karmic) saltwa...@karmic:~$ php -r 'echo PHP_INT_MAX."\n";' 9223372036854775807 saltwa...@karmic:~$ php -v PHP 5.2.10-2ubuntu5 with Suhosin-Patch 0.9.7 (cli) (built: Oct 13 2009 18:33:05) Copyright (c) 1997-2009 The PHP Group Zend Engine v2.2.0, Copyright (c) 1998-2009 Zend Technologies saltwa...@karmic:~$ php long.php saltwa...@karmic:~$ # again - no failure (Debian Lenny - Quick setup with Zend Server CE) r...@php-test:~# php -r 'echo PHP_INT_MAX."\n";' 9223372036854775807 r...@php-test:~# php -v PHP 5.3.0 (cli) (built: Jul 21 2009 08:21:24) Copyright (c) 1997-2009 The PHP Group Zend Engine v2.3.0, Copyright (c) 1998-2009 Zend Technologies with Zend Extension Manager v5.1, Copyright (c) 2003-2009, by Zend Technologies - with Zend Data Cache v4.0, Copyright (c) 2004-2009, by Zend Technologies [loaded] [licensed] [disabled] - with Zend Utils v1.0, Copyright (c) 2004-2009, by Zend Technologies [loaded] [licensed] [enabled] - with Zend Optimizer+ v4.0, Copyright (c) 1999-2009, by Zend Technologies [loaded] [licensed] [disabled] - with Zend Debugger v5.2, Copyright (c) 1999-2009, by Zend Technologies [loaded] [licensed] [enabled] r...@php-test:~# php long.php r...@php-test:~# # still nothing (Debian Lenny - same machine, my own build) r...@php-test:~# php -i | grep conf Configure Command => './configure' '--prefix=/opt/local' '--disable-cgi' '--with-layout=gnu' r...@php-test:~# php -r 'echo PHP_INT_MAX."\n";' 9223372036854775807 r...@php-test:~# php -v PHP 5.3.0 (cli) (built: Oct 23 2009 22:40:27) Copyright (c) 1997-2009 The PHP Group Zend Engine v2.3.0, Copyright (c) 1998-2009 Zend Technologies r...@php-test:~# php long.php r...@php-test:~# (CentOS 5.3 - Quick setup with Zend Server CE) [r...@php-test-cent ~]# php -r 'echo PHP_INT_MAX."\n";' [blah, some PHP strict timezone complains] 9223372036854775807 [r...@php-test-cent ~]# php -v PHP 5.3.0 (cli) (built: Aug 25 2009 03:54:07) Copyright (c) 1997-2009 The PHP Group Zend Engine v2.3.0, Copyright (c) 1998-2009 Zend Technologies with Zend Extension Manager v5.1, Copyright (c) 2003-2009, by Zend Technologies - with Zend Data Cache v4.0, Copyright (c) 2004-2009, by Zend Technologies [loaded] [licensed] [disabled] - with Zend Utils v1.0, Copyright (c) 2004-2009, by Zend Technologies [loaded] [licensed] [enabled] - with Zend Optimizer+ v4.0, Copyright (c) 1999-2009, by Zend Technologies [loaded] [licensed] [disabled] - with Zend Debugger v5.2, Copyright (c) 1999-2009, by Zend Technologies [loaded] [licensed] [enabled] [r...@php-test-cent ~]# php long.php [r...@php-test-cent ~]# # CentOS passes as well Previous Comments: ------------------------------------------------------------------------ [2009-10-23 19:25:26] paj...@php.net Also given that PHP_INT_MAX is 2147483647, having 3147483647 being stored as a float is perfectly valid. Try to confirm: > php -r "echo PHP_INT_MAX;" 2147483647 ------------------------------------------------------------------------ [2009-10-23 19:09:23] paj...@php.net #49492 was a complete bogus report, not sure why you even mention it here as it is unrelated. To clear some points before going further: - 5.2 has no x64 support on windows and will never have x64 support. - We use only VC9 for the x64 builds, with the SDK 6.1 About your reproduce code. Have you tried it on linux 64bit? I don't see a different behavior between linux and windows using 5.3. That's expected. It is also important to notice that 3147483647 is higher than 2^32 -1, which is the limit of the PHP integer. All in all I don's see that as a windows specific problem but about supporting large integers in a consistent manner. Given that we have it in our roadmap for future PHP versions, I will likely close this issue, once I have run some more tests. ------------------------------------------------------------------------ [2009-10-23 16:20:25] admin at saltwaterc dot net Description: ------------ The Windows x64 build of PHP has an issue with the integer data type. It may have issues with floating point numbers, but I didn't test it. The integer bugs me since I work with large integers as column primary keys in databases. I can't check for overflows with is_int() either (obvious). Runtime: - 3rd party PHP 5.2.5 x64 build - 3rd party PHP 5.2.8 x64 build - my own PHP 5.2.11 x64 builds - official snapshot PHP 5.3.1RC1 (used below) - so the issue is in both of the 5.2.x and 5.3.x branches Compiler - MSVC++ 8.0 Express - MSVC++ 9.0 Express Windows SDK: - 6.1a - 7.0 Since there were various versions built with various compilers and Windwows SDKs, I tend to believe that this is a PHP build system related issue, rather than an issue with that MSVC++ stuff. PS: at the moment this x64 issue is a development problem as the code goes into production on *nix machines with proper 64-bit support. Please don't tell me the same story from report #49492. Yes, Apache doesn't provide official x64 builds, but it is supported, thus 64-bit development is possible. Try it yourself: http://www.anindya.com/apache-http-server-2-2-14-x86-x64-msi-installers/ Reproduce code: --------------- <?php // long.php function assert_handler($file, $line, $code) { echo "Assertion Failed: File '$file' Line '$line' Code '$code'"; } assert_options(ASSERT_ACTIVE, 1); assert_options(ASSERT_WARNING, 0); assert_options(ASSERT_QUIET_EVAL, 1); assert_options(ASSERT_CALLBACK, 'assert_handler'); assert(is_int(3147483647) === TRUE); Expected result: ---------------- Nothing! Actual result: -------------- C:\Users\Saltwater\Desktop>php-5.3.1RC1-Win32-VC9-x64\php.exe long.php Assertion Failed: File 'C:\Users\Saltwater\Desktop\long.php' Line '13' Code '' C:\Users\Saltwater\Desktop> ------------------------------------------------------------------------ -- Edit this bug report at http://bugs.php.net/?id=49974&edit=1