Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:82731
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.220.169 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <7472A723-0408-4928-B06D-F0A1CE62EC73@ajf.me>
References: <6FD9B9A4-E831-4D4F-AD66-BD04D8C37991@ajf.me>
	<CAPwsocEiBZ4T+cBE_-FOfURxDwGK10ORZwjMSYbtDG9WgxVT_w@mail.gmail.com>
	<7472A723-0408-4928-B06D-F0A1CE62EC73@ajf.me>
Date: Sun, 15 Feb 2015 17:42:15 +0000
Message-ID: <CAPwsocGWQzzmv_QXZj5786_i72rkFH3_ZJiXddSHhHYKnYnTbA@mail.gmail.com>
To: Andrea Faulds <ajf@ajf.me>
Cc: PHP Internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] [VOTE] Big Integer Support
From: leight@gmail.com (Leigh)

On 15 February 2015 at 13:51, Andrea Faulds <ajf@ajf.me> wrote:
>> 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, sa=
y, what phpng did.

The real-world performance gains of ng are significant. Everything is
a trade-off. Having to change exts because the guys behind ng have
made (potentially) "80% of all websites" faster is acceptable - in my
opinion.

>> 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=
=99s a future possibility: since it would be made largely redundant by larg=
e 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 propo=
sal, it is merely a thought.

The GMP ext offers a lot more than arbitrary precision arithmetic.
There's a slew of functions there that go hand in hand with big ints
and their applications. gmp_inverse, gmp_powm and gmp_rootrem to name
a few. There are applications, both proprietary and open that depend
on these. I'd personally be willing to help bring more functionality
to ext/gmp rather than lose all of these important functions to PECL.

>> 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 extendi=
ng its range?

Among other thing the behaviour of overflow and shift operations are
well documented and understood quirks of fixed size integer types.

>> 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 safe=
ly on 32-bit, and we don=E2=80=99t require you to use a weird extension tha=
t may crash the PHP interpreter and DoS your web host in order to do large =
number arithmetic.

A weird extension? The base library of which you are using to back
your big int implementation.

DoS against libgmp is really stretching it here. Yes you can cause all
kinds of horrible crashes if you try and do something ridiculous, but
that's why you have a programming language that gives you everything
you need to sanitise inputs to prevent it.