Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:78073 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 4333 invoked from network); 14 Oct 2014 21:49:05 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 14 Oct 2014 21:49:05 -0000 Authentication-Results: pb1.pair.com smtp.mail=ajf@ajf.me; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=ajf@ajf.me; sender-id=pass Received-SPF: pass (pb1.pair.com: domain ajf.me designates 192.64.116.208 as permitted sender) X-PHP-List-Original-Sender: ajf@ajf.me X-Host-Fingerprint: 192.64.116.208 imap2-3.ox.privateemail.com Received: from [192.64.116.208] ([192.64.116.208:50748] helo=imap2-3.ox.privateemail.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 4B/19-18603-C4A9D345 for ; Tue, 14 Oct 2014 17:49:05 -0400 Received: from localhost (localhost [127.0.0.1]) by mail.privateemail.com (Postfix) with ESMTP id 607AA8C0083; Tue, 14 Oct 2014 17:48:57 -0400 (EDT) X-Virus-Scanned: Debian amavisd-new at imap2.ox.privateemail.com Received: from mail.privateemail.com ([127.0.0.1]) by localhost (imap2.ox.privateemail.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 12ikBwEmiFlO; Tue, 14 Oct 2014 17:48:57 -0400 (EDT) Received: from [172.20.10.4] (dab-crx1-h-1-2.dab.02.net [82.132.224.222]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.privateemail.com (Postfix) with ESMTPSA id BBEC98C0082; Tue, 14 Oct 2014 17:48:47 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) In-Reply-To: <543D8BEB.8000803@sugarcrm.com> Date: Tue, 14 Oct 2014 22:48:24 +0100 Cc: PHP Internals Content-Transfer-Encoding: quoted-printable Message-ID: <256CC066-BA1B-496E-9F5C-CA651B4B6161@ajf.me> References: <8C47FA53-0964-49C0-963C-332A936348A5@ajf.me> <543CE41B.5020308@sugarcrm.com> <543D5C78.9040905@sugarcrm.com> <3FB11875-5FEC-4CC1-BA13-D910F588D252@ajf.me> <543D6761.90201@sugarcrm.com> <630973F6-C5E7-4EE2-A7E4-46A1CC88A082@ajf.me> <543D6DFB.9050806@sugarcrm.com> <303FAFBC-7AEA-49A8-8A7D-67E66BF23E60@ajf.me> <543D8BEB.8000803@sugarcrm.com> To: Stas Malyshev X-Mailer: Apple Mail (2.1878.6) Subject: Re: [PHP-DEV] [RFC] Big Integer Support From: ajf@ajf.me (Andrea Faulds) On 14 Oct 2014, at 21:47, Stas Malyshev wrote: >> You throw an error. Just as plenty of functions already can=92t = handle >> ridiculously large integer arguments. >=20 > The problem is, if you function can handle the int range and you = checked > for is_int() and everything worked fine - now it's broken because > is_int() no longer implies fixed range and there's no way to check if > you're dealing with fixed-range number or infinite-range number. Yes, but you *can* check if the function errors. I don=92t really think = this is a massive problem. People will probably not realistically expect = that all functions can accept really large numbers, whether that range = cuts off at 2**64-1 or something more arbitrary. It=92s a problem if = abs() or sign() don=92t work for bigints. It isn=92t if str_repeat() = doesn=92t, because a similarly-sized non-bigint would error too. >=20 >> No, it does: There are now integers, and objects that represent large >> integers, which behave differently. >=20 > IS_INT and IS_BIGINT would necessarily behave differently too - since > some functions may support both and some only integers. All functions would =93support=94 both for integer arguments. But some = might choose to reject bigints which are larger than the internal = integer type the function uses=85 much like a function written for PHP = currently might reject longs larger than the internal integer type the = function uses. > Again, no change > here. The point is the degree to which they can act the same. Objects can only = go so far. -- Andrea Faulds http://ajf.me/