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] [email protected]
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] [email protected]
#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
