Re: [RFC] Big Integer Support

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