#49974 [Asn]: Windows x64 build lacks proper suport for 64-bit signed long long

[admin at saltwaterc dot net]

 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 31474836470 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;

#49974 [Asn]: Windows x64 build lacks proper suport for 64-bit signed long

[pajoye]

 ID:   49974
 Updated by:   paj...@php.net
 Reported By:  admin at saltwaterc dot net
 Status:   Assigned
 Bug Type: Scripting Engine problem
 Operating System: Windows x64, irrelevant version
 PHP Version:  5.2.11
 Assigned To:  pajoye
 New Comment:

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




Previous Comments:


[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\Desktopphp-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=49974edit=1