On 14 Oct 2014, at 19:39, Stas Malyshev <smalys...@sugarcrm.com> 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/





--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to