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 Developer Edit
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If you forgot your password, you can retrieve your password here.
Password:
Status:
Package:
Bug Type:
Summary:
From: admin at saltwaterc dot net
New email:
PHP Version: OS:

 

 [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

Pull Requests

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-2025 The PHP Group
All rights reserved. 		Last updated: Fri Oct 24 17:00:01 2025 UTC