On 14 Oct 2014, at 19:39, Stas Malyshev <[email protected]> wrote:
>> We already have this danger for another type: boolean. phpng got rid
>> of IS_BOOL in favour of IS_TRUE and IS_FALSE. If we can update
>> everything to handle the IS_BOOL change, surely we can update
>> everything to handle bigints, too.
>
> No, it's not the same thing at all. For bool, you still have only true
> and false. For bigint, your function now should be able to handle
> infinite integers internally, but what if it has fixed resources that
> assume integers have fixed range?
You throw an error. Just as plenty of functions already can’t handle ridiculously large integer
arguments.
> For extensions, it's a commonplace,
> but even for user code that can happen. That means, any call that you do
> to an internal function with int argument now could fail since the
> internal function is unable to support bigint, and you can't even guard
> for this since your code can not distinguish regular int from bigint. I
> don't think it is a good situation.
If a function can’t support a large integer argument, this is usually for an obvious reason. I am
not tormented daily in Python by the fact that I can’t seek by 2^69 bytes in a file, and I doubt
any PHP developer would be.
>
>> Then get weird results when someone passes a large number in.
>
> Why would you get weird results? You describe some vague dangers but I
> didn't see any concrete example of what is different.
Integers beyond 2^64 (on 64-bit systems) or 2^32 (on 32-bit systems) overflow to floats and lose
accuracy. Then, if they’re casted back to integers, are truncated silently and wrap around.
>
>> The main point of the RFC is to make integers completely consistent
>> across platforms and to remove the need to worry about overflow.
>
> Which does not change with my proposal.
No, it does: There are now integers, and objects that represent large integers, which behave
differently.
--
Andrea Faulds
http://ajf.me/