Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:75032
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.2\))
In-Reply-To: <CA+kxMuTFVEyHDErHC9iWf_h7wP_uUhJTPKAwT=mhBRy=itrm=w@mail.gmail.com>
Date: Sat, 21 Jun 2014 21:14:43 +0100
Cc: PHP Internals <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <0F4CED72-0292-4CC6-89DE-479668619D39@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)


On 21 Jun 2014, at 12:02, Dan Ackroyd <danack@basereality.com> wrote:

> An interesting RFC, that could do with some fleshing out.

Don=92t worry, I=92ll be sure to flesh it out further.

> What is the behaviour when you add 0.5 to a value that is a bigint?

That would come under TYPE_PAIR(IS_BIGINT, IS_DOUBLE) (or its opposite). =
It would cast the bigint to a float then add the two. The results would =
be similar to adding a large 64-bit long (over 53 bits) and a double. =
I=92m not sure what the exact result would be. For large values, 0.5 is =
probably just rounded away.

> What is the behaviour when a bigint zval is used in an extension that
> is then going to then pass it to an underlying library that is
> expecting a 64bit value? Will all the extension authors need to start
> casting and/or checking the values?

Functions expecting zvals will obviously need to start handling =
IS_BIGINT, so yes, you=92d need to check and cast if appropriate. =
Casting from a bigint to a long is easy, though, it=92s just =
zend_bigint_to_long(Z_LVAL_P(some_zval)). Obviously you could also =
export a double or a string in the same fashion. As I think I noted in =
the RFC, PHP functions which take longs already will continue to get =
longs, as bigints passed them will be casted.

> There are quite a few functions in the GMP library, which presumably
> are useful in handling bigints. Are these going to be exposed to
> users? If so, how?

I=92m exposing absolutely none of GMP directly and would rather not =
change that. Instead, I have the zend_bigint_* family, which are largely =
thin wrappers over GMP so you can deal with the zend_bigint type =
directly, and also so PHP is theoretically not GMP-dependent and could =
switch to another library. While I don=92t have the functions inlined at =
the moment (debugging convenience; make clean isn=92t fun!), they will =
be inlined eventually for performance. I agree that GMP=92s functions =
are useful, but I really don=92t want to directly expose the internal =
gmp type to anything outside of zend_bigint.c, so I guess any functions =
I haven=92t already covered will need their own wrappers created.

> 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.

I don=92t think the new behaviour will be confusing, as integers will =
simply be unbounded now so far as users need to be concerned. A benefit =
of doing it implicitly is that PHP=92s integer arithmetic would be =
completely consistent across platforms. Users don=92t have to worry =
about whether the machine their code is run on is 32-bit or 64-bit, and =
operations are consistent for different sizes of numbers. It also makes =
writing code easier, as users don=92t have to worry about if integers =
will suddenly overflow to float. Obviously, if you=92re using =
ridiculously big numbers you=92ll start hitting memory limits, but most =
of the time it means integers are effectively limitless.

> 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.

Right, the LGPL thing will need to be addressed. As far as I can see, =
there wouldn=92t really be any impact on PHP users, though I=92m not an =
open-source license expert. I can=92t really see it causing a particular =
problem unless people are distributing proprietary PHP versions, but I =
need to look into it more, so don=92t quote me on that.
--
Andrea Faulds
http://ajf.me/