Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:77877
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.216.169 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <5438F4D1.1080206@lsces.co.uk>
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>
Date: Sat, 11 Oct 2014 15:36:47 +0200
Message-ID: <CAEZPtU7atcsbEuCG5X_RqDZ5eFm2YrXD=vaZ6HbsCtRLzk0h_Q@mail.gmail.com>
To: Lester Caine <lester@lsces.co.uk>
Cc: PHP internals <internals@lists.php.net>, Andrea Faulds <ajf@ajf.me>
Content-Type: multipart/alternative; boundary=089e014953c0d335ac050525c138
Subject: Re: [PHP-DEV] [RFC] Big Integer Support
From: pierre.php@gmail.com (Pierre Joye)

--089e014953c0d335ac050525c138
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Oct 11, 2014 4:14 PM, "Lester Caine" <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=E2=80=99s not a =E2=80=9Cwrong approach=E2=80=9D.
> >> >
> >> > 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 =E2=80=
=A6
> > =E2=80=9CBigints=E2=80=9D typically refer to arbitrary-size integers, t=
hat is, their
size is bounded only by the amount of RAM available.
> >
> > I don=E2=80=99t know what you think a =E2=80=9Cbigint=E2=80=9D is, but =
it=E2=80=99s 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.

--089e014953c0d335ac050525c138--