Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:78047
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain ajf.me designates 192.64.116.216 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: <543D6761.90201@sugarcrm.com>
Date: Tue, 14 Oct 2014 19:24:57 +0100
Cc: PHP Internals <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <630973F6-C5E7-4EE2-A7E4-46A1CC88A082@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>
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:11, Stas Malyshev <smalyshev@sugarcrm.com> wrote:

> Hi!
>=20
>> Still, it=92s inconvenient. More for developers to worry about.
>=20
> I still have no idea why one would need a bigint constant, could you
> give an common example where you would do that?

The main point is why you should prohibit it. The point of bigints is to =
remove cross-platform integer differences. Why shouldn=92t you here? Why =
should I conditionally do different things on 64-bit and 32-bit?


>> No, only extensions. It is *completely* transparent to userland.
>> That=92s the whole point.
>=20
> I'm not sure how it can be completely transparent if it's a different
> type. Is it still identifying as int?

Yes.

> In this case, this is dangerous as
> some functions may not be able to accept big integers when accepting =
int
> arguments, but checks for is_int, etc. would pass.

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.

> If it's not, the extension has to handle it, the same way it has to
> handle bigint anyway if it makes difference for it. The point is many
> common cases are already covered, e.g. if the extension just needs a
> string, or if the bigint actually represents a small int, etc.

Many common cases are easily covered by a new type anyway. You =
overestimate the effort, I have already done the work, it=92s not much. =
Objects make nothing easier.

>=20
>> No, but existing code does have to handle float overflow. If you
>> allow that to optionally be int overflow, you now need to worry about
>> handling both.
>=20
> What's "float overflow=94?

Beyond PHP_INT_MAX, integers magically become floats in PHP. They have =
done so for a long time.

> I'm not sure I'm getting your point here. You
> don't need to handle anything - if your code doesn't care about big
> ints, you just do math as usual.

Then get weird results when someone passes a large number in.

> If it does, then you have to check big
> ints are there, then do math as usual but be aware that int can be now
> of two different types. I don't see any difference from the RFC here.

The main point of the RFC is to make integers completely consistent =
across platforms and to remove the need to worry about overflow. Adding =
optional overflow to GMP means you still have to worry about it. It =
doesn=92t solve anything. You can already use GMP for applications which =
explicitly need to use large numbers. This RFC doesn=92t exist for that =
purpose.

--
Andrea Faulds
http://ajf.me/