On 11/10/14 14:36, Pierre Joye wrote: > > On Oct 11, 2014 4:14 PM, "Lester Caine" <les...@lsces.co.uk > <mailto:les...@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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
