Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:78052
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain sugarcrm.com designates 108.166.43.91 as permitted sender)
Message-ID: <543D6DFB.9050806@sugarcrm.com>
Date: Tue, 14 Oct 2014 11:39:55 -0700
Organization: SugarCRM
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:31.0) Gecko/20100101 Thunderbird/31.1.2
MIME-Version: 1.0
To: Andrea Faulds <ajf@ajf.me>
CC: PHP Internals <internals@lists.php.net>
References: <8C47FA53-0964-49C0-963C-332A936348A5@ajf.me> <543CE41B.5020308@sugarcrm.com> <C545E75D-109A-4348-9B7E-CDE3A6FD6F57@ajf.me> <543D5C78.9040905@sugarcrm.com> <3FB11875-5FEC-4CC1-BA13-D910F588D252@ajf.me> <543D6761.90201@sugarcrm.com> <630973F6-C5E7-4EE2-A7E4-46A1CC88A082@ajf.me>
In-Reply-To: <630973F6-C5E7-4EE2-A7E4-46A1CC88A082@ajf.me>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] [RFC] Big Integer Support
From: smalyshev@sugarcrm.com (Stas Malyshev)

Hi!

> 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? 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.

> 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.

> 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.

> Adding optional overflow to GMP means you still have to worry about
> it. It doesn’t solve anything. You can already use GMP for

You seem to misunderstand what my proposal is. It doesn't add any
additional overflow, it just changes from using separate type
masquerading as int to using objects. All the rest stays the same.
-- 
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/