On 21 Jun 2014, at 12:02, Dan Ackroyd <danack@basereality.com> wrote:
> An interesting RFC, that could do with some fleshing out.
Don’t worry, I’ll 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’m 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’d need to check and cast if appropriate. Casting from a bigint to a long is easy, though, it’s 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’m 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’t have the functions inlined at the moment (debugging convenience; make clean isn’t fun!), they will be inlined eventually for performance. I agree that GMP’s functions are useful, but I really don’t want to directly expose the internal gmp type to anything outside of zend_bigint.c, so I guess any functions I haven’t 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’t 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’s integer arithmetic would be completely consistent across platforms. Users don’t 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’t have to worry about if integers will suddenly overflow to float. Obviously, if you’re using ridiculously big numbers you’ll 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.
>
> 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’t really be any impact on PHP users, though I’m not an open-source license expert. I can’t really see it causing a particular problem unless people are distributing proprietary PHP versions, but I need to look into it more, so don’t quote me on that.
--
Andrea Faulds
http://ajf.me/
