Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:77879
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain lsces.co.uk from 217.147.176.214 cause and error)
Message-ID: <54395567.6030509@lsces.co.uk>
Date: Sat, 11 Oct 2014 17:05:59 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.0
MIME-Version: 1.0
To: PHP internals <internals@lists.php.net>
References: <8C47FA53-0964-49C0-963C-332A936348A5@ajf.me>	<54385BC4.8030405@lsces.co.uk>	<D9BBD948-969E-42AC-A83A-927E6BE09E6E@ajf.me>	<54386E55.20407@lsces.co.uk>	<5A30388D-AD64-4C6A-8547-A0C98D834A8A@ajf.me>	<5438F4D1.1080206@lsces.co.uk> <CAEZPtU7atcsbEuCG5X_RqDZ5eFm2YrXD=vaZ6HbsCtRLzk0h_Q@mail.gmail.com>
In-Reply-To: <CAEZPtU7atcsbEuCG5X_RqDZ5eFm2YrXD=vaZ6HbsCtRLzk0h_Q@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] [RFC] Big Integer Support
From: lester@lsces.co.uk (Lester Caine)

On 11/10/14 14:36, Pierre Joye wrote:
> 
> On Oct 11, 2014 4:14 PM, "Lester Caine" <lester@lsces.co.uk
> <mailto:lester@lsces.co.uk>> wrote:
>>
>> On 11/10/14 01:18, Andrea Faulds wrote:
>> >>> >> What you want is 64-bit data handling. This is arbitrary-bit
> data handling. It’s not a “wrong approach”.
>> >> >
>> >> > So BIGINT on 32 bit platforms will be different to BIGINT on 64 bit
>> >> > platforms? BIGINT is a fix length number not a variable one …
>> > “Bigints” typically refer to arbitrary-size integers, that is, their
> size is bounded only by the amount of RAM available.
>> >
>> > I don’t know what you think a “bigint” is, but it’s different to
> everyone else.
>>
>> PLEASE rename the page name for this and stop using BIGINT for it ...
>>
>> BIGINT is the SQL99-compliant 64-bit signed integer type
>>
>> http://www.firebirdsql.org/refdocs/langrefupd25-bigint.html
>> http://www.postgresql.org/docs/9.1/static/datatype-numeric.html
>> http://dev.mysql.com/doc/refman/5.5/en/integer-types.html
>>
>> BIGINT is very much an 8 byte data value which we have been struggling
>> with on PHP for some time. Now that it's available in 64bit builds, we
>> need a simple transparent way to maintain that in 32bit builds ...
>>
>> If you are proposing BigInteger that is something else
>> http://docs.oracle.com/javase/7/docs/api/java/math/BigInteger.html and
>> GMP already provides that. Miking it up with the BIGINT standard which
>> is something we DO need is the problem here ...
> 
> No.
> 
> The problem is on the other end of the wire. Big integer concept, in a
> programming language context, or libraries (openssl, Crypto++, etc), is
> pretty clear.
> 
> Can we now move to discussions about the implementations and open
> questions? That will be much more useful.

BIGINT is a cleanly defined concept and something we have had to cope
with for some time since PHP does not support 64 bit integers cleanly.
Now that 64 bit builds support a clean 64 bit integer, the problem
arises that 32 bit builds will handle this in the old way.

I'll be quite frank,, and the idea of BigInteger was not something I was
even aware of but it does NOT use 'bigint' as a shorthand for it, so
mixing the two concepts up does not make any sense!

What needs tidying up here is the confusion being created for those of
us who use 'BIGINT' day in day out. GMP provides larger range integer
values, while the proposed rfc is ONLY describing handling 64 bit wrap
around ... which is what is needed to tidy up bigint handling on 32bit
platforms. There are two conflicting requirements which this rfc is
mixing up. Creating an unlimited integer size via GMP should correctly
fix all of the knock on effects such as shift on the whole integer
rather than just 64bits of it. While on the other hand, we need a clean
bigint alternative for 32bit platforms to mirror that on 64bit builds
... which does not involve GMP

-- 
Lester Caine - G8HFL
-----------------------------
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk