rfc:bigint
Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revisionLast revisionBoth sides next revision | ||
rfc:bigint [2015/02/15 01:24] – v0.1.8 - Decided on not touching float indexing behaviour for now ajf | rfc:bigint [2015/02/15 21:06] – Withdrew RFC and cancelled vote ajf | ||
---|---|---|---|
Line 1: | Line 1: | ||
====== PHP RFC: Big Integer Support ====== | ====== PHP RFC: Big Integer Support ====== | ||
* Version: 0.1.8 | * Version: 0.1.8 | ||
- | * Date: 2014-06-20 (Initial Draft; Put Under Discussion 2014-10-10, Last updated 2015-01-10) | + | * Date: 2014-06-20 (Initial Draft; Put Under Discussion 2014-10-10, Last updated 2015-02-15) |
* Author: Andrea Faulds, ajf@ajf.me | * Author: Andrea Faulds, ajf@ajf.me | ||
- | * Status: | + | * Status: |
* First Published at: http:// | * First Published at: http:// | ||
Line 36: | Line 36: | ||
==== Standard library changes ==== | ==== Standard library changes ==== | ||
- | * All math functions are updated | + | * Some math functions |
- | * '' | + | * '' |
+ | * '' | ||
+ | * '' | ||
+ | * '' | ||
+ | * '' | ||
+ | | ||
+ | * '' | ||
+ | * Serialisation and unserialisation supports bigints | ||
+ | * '' | ||
==== Examples ==== | ==== Examples ==== | ||
Line 102: | Line 110: | ||
===== Proposed PHP Version(s) ===== | ===== Proposed PHP Version(s) ===== | ||
- | This is proposed for the next PHP X, currently PHP 7. The patch is based off of phpng, and my intention is for it to be merged into phpng. | + | This is proposed for the next PHP X, currently PHP 7. The patch is based on PHP master (originally, phpng). |
===== RFC Impact ===== | ===== RFC Impact ===== | ||
Line 116: | Line 124: | ||
Firstly, if you do an operation resulting in an extremely large number, you might hit your request memory limit. | Firstly, if you do an operation resulting in an extremely large number, you might hit your request memory limit. | ||
- | Secondly, when trying to calculate a value that would require more memory than size_t can describe, GMP prints the '' | + | Secondly, when trying to calculate a value that would require more memory than '' |
==== Licensing and dependency issues ==== | ==== Licensing and dependency issues ==== | ||
- | I am current porting this to use [[http:// | + | To avoid implementing the underlying arithmetic itself, PHP needs to add a dependency on a library implementing |
- | At compile-time, it is also possible | + | This patch supports two different libraries, which you can choose between when compiling PHP: |
+ | |||
+ | * [[http:// | ||
+ | * [[https:// | ||
+ | |||
+ | A choice is allowed to avoid licensing issues with GMP: while it has better performance, | ||
==== Arrays ==== | ==== Arrays ==== | ||
- | Since '' | + | Since '' |
==== To SAPIs ==== | ==== To SAPIs ==== | ||
Line 134: | Line 147: | ||
==== To Existing Extensions ==== | ==== To Existing Extensions ==== | ||
- | Any which request numeric parameters as zvals rather than longs or doubles from zend_parse_parameters will need changes. Those dealing with numerical operations specifically will require deeper changes. Obviously, ext/ | + | Any extensions |
ext/gmp will be updated to handle bigints. However, due to behavioural and implementation differences between GMP objects and the bigint type, it won't just pass through to the built-in operator functions. With the addition of bigints, ext/gmp would quickly become irrelevant except for backwards-compatibility with existing applications, | ext/gmp will be updated to handle bigints. However, due to behavioural and implementation differences between GMP objects and the bigint type, it won't just pass through to the built-in operator functions. With the addition of bigints, ext/gmp would quickly become irrelevant except for backwards-compatibility with existing applications, | ||
Line 144: | Line 157: | ||
Both GMP and LibTomMath can only have one custom allocator, so I weighed the options and made that be emalloc, not malloc. I expect this would pose a problem for opcache, as any bigints would be destroyed upon the end of a request, so opcache would need to store bigints persistently. Hence, some sort of import/ | Both GMP and LibTomMath can only have one custom allocator, so I weighed the options and made that be emalloc, not malloc. I expect this would pose a problem for opcache, as any bigints would be destroyed upon the end of a request, so opcache would need to store bigints persistently. Hence, some sort of import/ | ||
- | I have not yet dealt with opcache | + | The patch has not yet been updated to support |
==== New Constants ==== | ==== New Constants ==== | ||
Line 201: | Line 214: | ||
===== Unaffected PHP Functionality ===== | ===== Unaffected PHP Functionality ===== | ||
- | As previously mentioned, the handling of array keys might need to be looked at. Otherwise, it shouldn' | + | As previously mentioned, the handling of array keys might need to be looked at. Otherwise, it shouldn' |
===== Future Scope ===== | ===== Future Scope ===== | ||
Line 207: | Line 220: | ||
None I can think of particularly. | None I can think of particularly. | ||
- | ===== Proposed Voting Choices | + | ===== Vote ===== |
+ | |||
+ | As this is a language change (it affects the language specification), | ||
+ | |||
+ | Voting started on 2015-02-15 and was to end 10 days later on 2015-02-25, but voting was cancelled the same day it started. | ||
- | In some respects this is just an implementation detail, but as this would break backwards-compatibility for some apps and arguably changes the language, I think this requires a 2/3 majority. It would be a straight | + | <doodle title=" |
+ | | ||
+ | * No | ||
+ | </doodle> | ||
===== Patches and Tests ===== | ===== Patches and Tests ===== |
rfc/bigint.txt · Last modified: 2017/09/22 13:28 by 127.0.0.1