Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:81930
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.180 as permitted sender)
Message-ID: <54D37D09.6050803@gmail.com>
Date: Thu, 05 Feb 2015 14:24:09 +0000
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: internals@lists.php.net
References: <54D34CD6.6020401@lsces.co.uk> <585A6531-BFF1-4B40-9052-518518A9409F@ajf.me> <54D36322.8080805@lsces.co.uk> <54D372CD.5070007@gmail.com> <54D377AF.9030009@gmx.de>
In-Reply-To: <54D377AF.9030009@gmx.de>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] hints and constraints
From: rowan.collins@gmail.com (Rowan Collins)

Christoph Becker wrote on 05/02/2015 14:01:
> 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

Regards,
-- 
Rowan Collins
[IMSoP]