Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:82726
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain ajf.me designates 192.64.116.200 as permitted sender)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\))
In-Reply-To: <CAPwsocEiBZ4T+cBE_-FOfURxDwGK10ORZwjMSYbtDG9WgxVT_w@mail.gmail.com>
Date: Sun, 15 Feb 2015 13:51:47 +0000
Cc: PHP Internals <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <7472A723-0408-4928-B06D-F0A1CE62EC73@ajf.me>
References: <6FD9B9A4-E831-4D4F-AD66-BD04D8C37991@ajf.me> <CAPwsocEiBZ4T+cBE_-FOfURxDwGK10ORZwjMSYbtDG9WgxVT_w@mail.gmail.com>
To: Leigh <leight@gmail.com>
Subject: Re: [PHP-DEV] [VOTE] Big Integer Support
From: ajf@ajf.me (Andrea Faulds)

Hi,

> On 15 Feb 2015, at 13:07, Leigh <leight@gmail.com> wrote:
>=20
> I think this adds a ton of unnecessary complexity and isn't worth the
> breaks or performance degradations that come with it.
>=20
> We already have big integer support in the form of the GMP extension,
> and it is very clear when you are working with arbitrary length
> integers. But instead this patch adds GMP as a dependency and hides it
> away internally (or for a bigger performance hit, LibTomMath).
>=20
> Extensions "that deal with numbers" are all going to need updating. So
> probably every extension?

Anything accepting a zval rather than a long through zpp, but the =
changes are quite small in most cases. It=E2=80=99s a much smaller =
change than, say, what phpng did.=20

> You talk about eventually deprecating ext/gmp and moving it to PECL.
> Definitely not acceptable.

I *talk* about it. I=E2=80=99m not saying we=E2=80=99ll do it. It=E2=80=99=
s a future possibility: since it would be made largely redundant by =
large integer support in core, we might eventually get rid of it.

I said =E2=80=9Cmight=E2=80=9D because it=E2=80=99s not part of the =
proposal, it is merely a thought.

> Sorry, the fixed size integer data type is far too baked-in and
> useful.

I could understand your perspective if PHP had modular arithmetic like C =
and such, but it doesn=E2=80=99t. So I don=E2=80=99t understand why it =
is =E2=80=9Cfar too useful=E2=80=9D - what usefulness is being lost by =
extending its range?

> I don't see any gain from this patch except hidden performance
> penalties, breaks, and extra work for everyone in maintaining it and
> other extensions. I'd rather big int usage was kept verbose and
> conscious.

I see a clear gain: we clean up almost every integer overflow edge case, =
integer overflow handling is more intuitive, we support large integers =
safely on 32-bit, and we don=E2=80=99t require you to use a weird =
extension that may crash the PHP interpreter and DoS your web host in =
order to do large number arithmetic.

--
Andrea Faulds
http://ajf.me/