Lester Caine wrote on 04/02/2015 00:49:
On 03/02/15 22:35, Andrea Faulds wrote:
>>Currently we have a problem with the size of integers, but simply
>> >ignoring that there are limits is not the may to fix that problem.
>This RFC doesn’t ignore that there are limits. Arbitrary-precision integers
are, naturally, bounded by available RAM (including the request memory limit).
BUT the whole problem currently IS the crap way 32bit integers roll over
to float. And trying to handle 64bit integers currently on PHP IS a
problem because of it.
And Andrea's proposal fixes that problem, so, that's a good thing...?
If I could ignore the 32bit
builds then I would and then all that is required is something to switch
off rolling out of the 64 bit integer and only support 64bit servers,
but the remote machines are all going to be 32bit.
...
strict types should know
that only an integer of a certain range is acceptable otherwise we have
to add THAT at the library level.
If an extension needs to deal with remote/foreign data, it is up to that
extension to deal with conversion and limits. The internal API's job is
to make it easy for the extension developer to handle the cases they
need - macros for range checks, automatically packing and unpacking
oversized binary integers, etc. This would be true even if PHP only
supported a single size of integer across all builds.
For instance, if the foreign data is a 16-bit integer, then input from
PHP needs to be range-checked even on a 32-bit build. This checking can
currently be skipped for the cases of foreign=32-bit, PHP=32-bit and
foreign=64-bit, PHP=64-bit, but must be done anyway for foreign=32-bit,
PHP=64-bit. With arbitrary-size integers as proposed here, the same
range checking needs to happen in a few more cases, as 32-bit PHP builds
may produce integers above 2**31, and 64-bit PHP builds may produce
integers above 2**63. But a decent API could let you always check and
short-cut itself where possible anyway.
At the other end of the scale, a 128-bit integer in foreign data cannot
currently be pushed into an integer on any PHP build. One possible way
of handling them is to switch to strings above 2**63 or 2**31, depending
on PHP build. This then reintroduces the need for range-checking, as PHP
code might give you a string representing a number above 2**127. The
same handling could be done for foreign 64-bit integers on 32-bit PHP
builds, but this leaks low-level information to the PHP user who really
shouldn't care about it. With the proposed changes, the extension would
instead marshall the values into a "BigInt", and the PHP user would be
complete unaware that it had happened.
I can see the reasoning that this change might be overkill, although it
seems performance has been taken into account in the implementation. I
fail to see how being able to support 128-bit integers on 64-bit
platforms as well as 64-bit integers on 32-bit platforms, using the same
set of macros, is anything other than a bonus.
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
