On Oct 11, 2014 4:14 PM, "Lester Caine" <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.
