Intval problems with different maximum range on win7x64 and CentOS

has been developed using win7x64, a Web server with a php5.5 built-in Web server,
Yesterday suddenly found a problem, the same code, on Win7 and CentOS, the results are different:
Var_dump (intval (' 21474836470 '));
Output on Win7: int 2147483647
In CentOS output: int 30000000000

The manual says:
The maximum value depends on the operating system. 32-bit system maximum signed integer range is 2147483648 to 2147483647
On a 64-bit system, the maximum signed integer value is 9223372036854775807.

But my system is win7x64 ah, download PHP also verified the next, is the 64-bit version,
Why does it appear that Intval is a 32-bit effect???
Looking at phpinfo under Windows, you can also see that it is 64-bit:
PHP Version 5.5.14
System Windows NT 7d494368868afa1 6.1 build 7601 (Windows 7 Ultimate Edition Service Pack 1) AMD64
Build Date June 25 2014 12:37:32
Compiler MSVC11 (Visual C + + 2012)
Architecture x64

Reply to discussion (solution)

This not only depends on the operating system version, but also the version of PHP, the official release of PHP version is 32-bit

php5.5 more than 64, the others are 32-bit

php5.5 more than 64, the others are 32-bit

My PHP is the 64-bit version of 5.5,
Also attached how to determine whether EXE is a 32-bit or 64-bit program, with the UE open EXE, near the 00000100h line, there will be a value:
"PE.. L "(hex code:504500004c) = + bit
Or
"PE.. D? " (hex code:504500006486) = a bit

No one knows???
Do we all only develop on win, or only on Linux?

Whether you need to develop with a 64-bit version depends on the operating environment.
Otherwise, your project will be aborted due to the 64-bit server not being found.
In addition, 64-bit systems are true and false: 64-bit system 64-bit architecture and 64-bit system 32-bit architecture (32-bit and quasi-32-bit in 32-bit systems)

Then there is, or the problem with you may be a bug (can be found on the bug site) is now 5.6.9, may have been repaired?

Whether you need to develop with a 64-bit version depends on the operating environment.
Otherwise, your project will be aborted due to the 64-bit server not being found.
In addition, 64-bit systems are true and false: 64-bit system 64-bit architecture and 64-bit system 32-bit architecture (32-bit and quasi-32-bit in 32-bit systems)

Then there is, or the problem with you may be a bug (can be found on the bug site) is now 5.6.9, may have been repaired?

Thanks for the reply, went to https://bugs.php.net/search, did not find the relevant bug information,
In addition, to the WINDOWS2008R2 Enterprise version of the test, but also the largest only supported: 2147483647

It seems that the follow-up should be migrated to CentOS to develop, to avoid this environment inconsistency problem

In addition, I ask the question, there is a place to write the wrong, but can not edit, should be the problem is:
Var_dump (intval (' 30000000000 '));
Output on Win7: int 2147483647
In CentOS output: int 30000000000

To mention a bug, replied that this is not a bug,
The Windows version of PHP is just the beta version, not exactly,
https://bugs.php.net/bug.php?id=69704

In fact, even if the support of 64-bit integer number, it still has a hidden danger, if you are more than the result of the 64-bit integer number?
PHP provides a high-precision number of operation function library, not affected by the machine, hundreds of billions (not hundreds of billions, only 10-bit) number can still be calculated

In fact, even if the support of 64-bit integer number, it still has a hidden danger, if you are more than the result of the 64-bit integer number?
PHP provides a high-precision number of operation function library, not affected by the machine, hundreds of billions (not hundreds of billions, only 10-bit) number can still be calculated

Now the business scenario is the user table of the self-increment ID, has exceeded the 32-bit valid range of values, resulting in development errors, the line is normal,
64-bit valid range of values, estimated at least after 10, even if I can see that day is not necessarily, haha

If it is a self-increment ID, then MySQL provides the BIGINT itself as a 64-bit integer
In PHP as a string processing can be, the self-increment ID is only an identity, do not participate in mathematical operations

If it is a self-increment ID, then MySQL provides the BIGINT itself as a 64-bit integer
In PHP as a string processing can be, the self-increment ID is only an identity, do not participate in mathematical operations

Yes, before processing is to convert a string to a number using intval, participate in SQL query,
After discovering that there was this problem,
Use regular ^/d+$ to determine if numbers, and then participate in SQL queries

Does the number in the SQL instruction you write do not enclose the quotation marks?
Although aaa=123 and aaa= ' 123 ' are the same, the latter is far safer than the former

Does the number in the SQL instruction you write do not enclose the quotation marks?
Although aaa=123 and aaa= ' 123 ' are the same, the latter is far safer than the former

Well, my side of SQL is not stitching, is like where id=? In this protocol, the resulting SQL is quoted.

