php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Bug #49974 Windows x64 build lacks proper suport for 64-bit signed long long
Submitted: 2009-10-23 16:20 UTC Modified: 2009-10-23 23:27 UTC
From: admin at saltwaterc dot net Assigned: pajoye (profile)
Status: Not a bug Package: Scripting Engine problem
PHP Version: 5.2.11 OS: win32 only - Windows x64
Private report: No CVE-ID: None
View Add Comment Developer Edit
 [2009-10-23 16:20 UTC] 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>

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2009-10-23 19:09 UTC] pajoye@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 19:25 UTC] pajoye@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 23:18 UTC] admin at saltwaterc dot net 
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)
remote@ubuntuvz:~$ php -r 'echo PHP_INT_MAX."\n";'
9223372036854775807
remote@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
remote@ubuntuvz:~$ php long.php 
remote@ubuntuvz:~$ # no failure here
(Debian Lenny)
saltwater@web:~$ php -r 'echo PHP_INT_MAX."\n";'
9223372036854775807
saltwater@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
saltwater@web:~$ php long.php
saltwater@web:~$ # no failure here either
(Ubuntu Karmic)
saltwater@karmic:~$ php -r 'echo PHP_INT_MAX."\n";'
9223372036854775807
saltwater@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
saltwater@karmic:~$ php long.php
saltwater@karmic:~$ # again - no failure

(Debian Lenny - Quick setup with Zend Server CE)
root@php-test:~# php -r 'echo PHP_INT_MAX."\n";'
9223372036854775807
root@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]
root@php-test:~#  php long.php
root@php-test:~#  # still nothing
(Debian Lenny - same machine, my own build)
root@php-test:~# php -i | grep conf
Configure Command =>  './configure'  '--prefix=/opt/local' '--disable-cgi' '--with-layout=gnu'
root@php-test:~# php -r 'echo PHP_INT_MAX."\n";'
9223372036854775807
root@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
root@php-test:~# php long.php
root@php-test:~# 
(CentOS 5.3 - Quick setup with Zend Server CE)
[root@php-test-cent ~]# php -r 'echo PHP_INT_MAX."\n";'
[blah, some PHP strict timezone complains]
9223372036854775807
[root@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]
[root@php-test-cent ~]# php long.php
[root@php-test-cent ~]# # CentOS passes as well
 [2009-10-23 23:27 UTC] pajoye@php.net 
no.

PHP int are long, long long does not exist anyway and are undefined sizes in many cases.

That's a feature request for portable large integers and we already have one > bogus.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved. 		Last updated: Tue Apr 16 13:01:30 2024 UTC