Lester Caine wrote on 05/02/2015 14:51:
On 05/02/15 14:24, Rowan Collins wrote:
There is nothing new about PHP's userland int type being 64-bit on
64-bit platforms. For instance, raising 2 to the power of 62 returns
exactly the same thing on every version of PHP back to 4.3.0:
http://3v4l.org/VBMbv
Unfortunately, that's not true for Windows, see
<http://windows.php.net/download/#x64>:
| The x64 builds of PHP for Windows should be considered experimental,
| and do not yet provide 64-bit integer or large file support. Please
| see this post for work ongoing to improve these builds.
Yes, the picture on Windows is rather different, hence my second comment
that most production builds of PHP are probably on (64-bit) Linux.
The point is that writing code in PHP and assuming integers will
overflow after 32 bits has been a bad idea for a long time, outside of
really unusual cases like COM integration [1], where there's a valid
reason to assume you'll never want to run it on Linux.
[1] http://php.net/manual/en/book.com.php
This is all past history ...
Those of us who have had to support windows only sites in the past have
often run 32 bit builds of Linux simply to maintain some level of
compatibility. It is the growing switch to 64bit builds of PHP5 that are
highlight many of the problems that we NOW want to fix things for which
wrong decisions in the past are catching up with us. Overflowing to
float had good reason for some users but not for others and now is the
time to sort out the whole mess.
That sounds like a pretty good argument in favour of Andrea's RFC to me.
The simple answer here is that there is not a 'single' definition of
integer ...
True. But the definition of "integer" in PHP is, and has been for many
years, "as big as this build can handle". With Andrea's patch, all
systems can handle really really big integers, which seems like a big
win to me.
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
