Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:75038
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=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\))
In-Reply-To: <CA+kxMuTFVEyHDErHC9iWf_h7wP_uUhJTPKAwT=mhBRy=itrm=w@mail.gmail.com>
Date: Sun, 22 Jun 2014 16:20:30 +0100
Cc: PHP Internals <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <1D1DE250-D3B5-4376-93D7-F5F7722D2389@ajf.me>
References: <EFEB30F4-3F52-44B3-98CE-9DD29ED08E74@ajf.me> <CA+kxMuTFVEyHDErHC9iWf_h7wP_uUhJTPKAwT=mhBRy=itrm=w@mail.gmail.com>
To: Dan Ackroyd <danack@basereality.com>
Subject: Re: [PHP-DEV] [DRAFT][RFC] Big Integer Support
From: ajf@ajf.me (Andrea Faulds)

Good afternoon,

I=92ve made some improvements to the RFC.

First, to address Dan=92s questions:

On 21 Jun 2014, at 12:02, Dan Ackroyd <danack@basereality.com> wrote:

> Finally, the RFC should probably address the licensing issues that
> would be involved in making GMP an integral part of PHP, not just for
> how PHP is distributed, but also for how people making and
> distributing PHP applications would be affected.
>=20
> For reference the GMP library is dual-licensed under GNU LGPL v3 and
> GNU GPL v2.0. As I understand it, these are not compatible with the
> PHP license.

I=92ve now addressed the licensing issues more thoroughly:

https://wiki.php.net/rfc/bigint#licensing_and_dependency_issues

> Most of all though, it could do with a stronger argument for why
> handling bigints 'automagically' like this is preferable to handling
> them explicitly. Without great care for handling them, dealing with
> very large numbers is still going to fail at some point. Although
> handling integers as bigints explicitly is more code to write, it's
> also results in more understandable behaviour, which seems better to
> me than having more internal converting of types which is not visible
> in userland.

The opening section now elaborates a little more on why I think bigints =
are beneficial:

https://wiki.php.net/rfc/bigint#introduction

I also think that having integers be effectively boundless would be more =
understandable than how they overflow to floats at the moment, =
especially for newbie programmers. More generally, it=92s less bugs and =
less worrying about platform differences.


Now onto Nikita=92s:

On 20 Jun 2014, at 15:58, Nikita Popov <nikita.ppv@gmail.com> wrote:

> Could you please submit a PR from your branch, so it's possible to =
review
> the code?

This has now been done: https://github.com/php/php-src/pull/700

I also lengthened my TODO list for things that are unfinished in the =
patch: https://wiki.php.net/rfc/bigint#todo

> Regarding the RFC text, I think you mixed up some left and right =
shifts.
> "<< 65 will result in zero" is probably supposed to be >> 65? And =
"right
> shifts will promote to bigints" probably is talking about left shifts?
>=20
> Btw, I wouldn't worry about the change in shifts larger than the =
integer
> width. Those have always been UB inherited from using UB of the C =
language.
> The cyclic behavior is only an idiosyncrasy of the x86 architecture - =
other
> ISAs like ARM (iirc) will not exhibit the behavior.


I=92ve fixed those errors and clarified this a bit, and I also mention =
that I removed negative shifts, which I had forgotten earlier:

=
https://wiki.php.net/rfc/bigint#changes_to_operators_for_the_sake_of_consi=
stency

Thanks for your comments!
--
Andrea Faulds
http://ajf.me/