Re: [RFC] Big Integer Support

From: Date: Tue, 14 Oct 2014 19:56:52 +0000
Subject: Re: [RFC] Big Integer Support
References: 1 2 3 4 5 6 7 8 9 10  Groups: php.internals 
Request: Send a blank email to internals+get-78060@lists.php.net to get a copy of this message
On 14 Oct 2014, at 20:46, Rowan Collins <rowan.collins@gmail.com> wrote: > Just to break this down a bit: > > 1) The RFC should probably aim to make array keys consistent across platforms. This is > currently left as an unanswered question in the RFC, but it seems natural to include it if the > stated aim is to eliminate inconsistencies. It’s something I do have an answer for, but it’ll be a separate RFC which I need to write a patch for and have pass before this one. > 2) By using an unlimited type, we open the door to constructing "integer"-keyed > arrays from 128-bit or larger sources. We also eliminate weirdness encountered at the boundaries, > such as $foo[PHP_MAX_INT] = 'hello'; $foo[] = 'world'; - see > http://3v4l.org/69mif That’s something which I would handle in the aforementioned not-yet-existant RFC. > 3) On the other hand, an implementation might be possible that allowed 64-bit integers on > 32-bit systems, but nothing more; this would potentially be both simpler and more efficient. More efficient, as in faster? Sure, that’d be faster. Simpler? Not really. The main difficulty in this patch is updating thousands of tests and functions. The basics of it (the new type, changes to operators) are very easy. > Implementing both is probably a bad idea, as some core code would then need to handle 3 > different types of integer (native, emulated 64-bit, and GMP), but it could be looked at as an > alternative if the current RFC is rejected on complexity or licensing grounds. As all bigint ops are abstracted, you could modify the patch to implement 64-bit integers if you wanted. Granted, they’d be unnecessarily allocated their own memory, but it’d be doable. -- Andrea Faulds http://ajf.me/

« previous php.internals (#78060) next »