Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:78055
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain ajf.me designates 198.187.29.245 as permitted sender)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
In-Reply-To: <543D6DFB.9050806@sugarcrm.com>
Date: Tue, 14 Oct 2014 20:44:43 +0100
Cc: PHP Internals <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <303FAFBC-7AEA-49A8-8A7D-67E66BF23E60@ajf.me>
References: <8C47FA53-0964-49C0-963C-332A936348A5@ajf.me> <543CE41B.5020308@sugarcrm.com> <C545E75D-109A-4348-9B7E-CDE3A6FD6F57@ajf.me> <543D5C78.9040905@sugarcrm.com> <3FB11875-5FEC-4CC1-BA13-D910F588D252@ajf.me> <543D6761.90201@sugarcrm.com> <630973F6-C5E7-4EE2-A7E4-46A1CC88A082@ajf.me> <543D6DFB.9050806@sugarcrm.com>
To: Stas Malyshev <smalyshev@sugarcrm.com>
Subject: Re: [PHP-DEV] [RFC] Big Integer Support
From: ajf@ajf.me (Andrea Faulds)


On 14 Oct 2014, at 19:39, Stas Malyshev <smalyshev@sugarcrm.com> wrote:

>> We already have this danger for another type: boolean. phpng got rid
>> of IS_BOOL in favour of IS_TRUE and IS_FALSE. If we can update
>> everything to handle the IS_BOOL change, surely we can update
>> everything to handle bigints, too.
>=20
> No, it's not the same thing at all. For bool, you still have only true
> and false. For bigint, your function now should be able to handle
> infinite integers internally, but what if it has fixed resources that
> assume integers have fixed range?

You throw an error. Just as plenty of functions already can=92t handle =
ridiculously large integer arguments.

> For extensions, it's a commonplace,
> but even for user code that can happen. That means, any call that you =
do
> to an internal function with int argument now could fail since the
> internal function is unable to support bigint, and you can't even =
guard
> for this since your code can not distinguish regular int from bigint. =
I
> don't think it is a good situation.

If a function can=92t support a large integer argument, this is usually =
for an obvious reason. I am not tormented daily in Python by the fact =
that I can=92t seek by 2^69 bytes in a file, and I doubt any PHP =
developer would be.

>=20
>> Then get weird results when someone passes a large number in.
>=20
> Why would you get weird results? You describe some vague dangers but I
> didn't see any concrete example of what is different.

Integers beyond 2^64 (on 64-bit systems) or 2^32 (on 32-bit systems) =
overflow to floats and lose accuracy. Then, if they=92re casted back to =
integers, are truncated silently and wrap around.

>=20
>> The main point of the RFC is to make integers completely consistent
>> across platforms and to remove the need to worry about overflow.
>=20
> Which does not change with my proposal.

No, it does: There are now integers, and objects that represent large =
integers, which behave differently.

--
Andrea Faulds
http://ajf.me/