Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:78045
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain sugarcrm.com designates 108.166.43.83 as permitted sender)
Message-ID: <543D6761.90201@sugarcrm.com>
Date: Tue, 14 Oct 2014 11:11:45 -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>
In-Reply-To: <3FB11875-5FEC-4CC1-BA13-D910F588D252@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!

> Still, it’s inconvenient. More for developers to worry about.

I still have no idea why one would need a bigint constant, could you
give an common example where you would do that?

> No, only extensions. It is *completely* transparent to userland.
> That’s the whole point.

I'm not sure how it can be completely transparent if it's a different
type. Is it still identifying as int? In this case, this is dangerous as
some functions may not be able to accept big integers when accepting int
arguments, but checks for is_int, etc. would pass.

> Yes, but they don’t handle large integer objects already. So you pass
> it a GMP object, it converts to a string, then that overflows and you
> end up with a float when it converts it to a number. Which isn’t what
> you wanted. Or, it handles it as a string, which is also not ideal,
> as while a string and an int may be the same thing to some
> extensions, they are not to others.

If it's not, the extension has to handle it, the same way it has to
handle bigint anyway if it makes difference for it. The point is many
common cases are already covered, e.g. if the extension just needs a
string, or if the bigint actually represents a small int, etc.

> It’s not about “extensions your code needs”. If you need ext/gmp, you
> can already require it. This RFC is about removing cross-platform
> integer handling differences.

But nothing changes there - it is still removing the diffs and it still
requires GMP. The only change is you're not paying for it if you don't
need it.

> No, but existing code does have to handle float overflow. If you
> allow that to optionally be int overflow, you now need to worry about
> handling both.

What's "float overflow"? I'm not sure I'm getting your point here. You
don't need to handle anything - if your code doesn't care about big
ints, you just do math as usual. If it does, then you have to check big
ints are there, then do math as usual but be aware that int can be now
of two different types. I don't see any difference from the RFC here.
-- 
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/