Hi, > On 15 Feb 2015, at 13:07, Leigh <lei...@gmail.com> wrote: > > I think this adds a ton of unnecessary complexity and isn't worth the > breaks or performance degradations that come with it. > > 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). > > 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’s a much smaller change than, say, what phpng did. > You talk about eventually deprecating ext/gmp and moving it to PECL. > Definitely not acceptable. I *talk* about it. I’m not saying we’ll do it. It’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 “might” because it’s 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’t. So I don’t understand why it is “far too useful” - 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’t 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/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
