Size of integer

php.internals

Lester Caine

22 years ago
An interesting little question has pooped up. How big is an integer? Firebird uses BIGINT or INT_64 for generator values, and the new ibase_gen_id in PHP5 returns that value as an integer. Has any thought been given to managing 64bit field values in PHP5?
-- Lester Caine ----------------------------- L.S.Caine Electronic Services

Andrey Hristov

22 years ago
Lester Caine wrote:
> An interesting little question has pooped up. > > How big is an integer? > > Firebird uses BIGINT or INT_64 for generator values, and the new > ibase_gen_id in PHP5 returns that value as an integer. > > Has any thought been given to managing 64bit field values in PHP5? >
Hi, AFAIK ext/mysqli returns string in case the int value is too big to fit into 32 bits. After that it's up to the user to decide what to do -> cast to float or use bcmath . HTH, Andrey

Lester Caine

22 years ago
Andrey Hristov wrote:
> Lester Caine wrote: > >> An interesting little question has popped up. >> >> How big is an integer? >> >> Firebird uses BIGINT or INT_64 for generator values, and the new >> ibase_gen_id in PHP5 returns that value as an integer. >> >> Has any thought been given to managing 64bit field values in PHP5? >>
> AFAIK ext/mysqli returns string in case the int value is too big to fit > into 32 bits. > After that it's up to the user to decide what to do -> cast to float or > use bcmath .
That will probably work for returning field values in a result set, the particular problem I am looking at is a function that is defined as returning an integer, but which could potentially contain a 64 bit value. Is any work being done on handling THAT potential time bomb?
-- Lester Caine ----------------------------- L.S.Caine Electronic Services

Andi Gutmans

22 years ago
At 09:03 PM 4/17/2004 +0100, Lester Caine wrote:
>>AFAIK ext/mysqli returns string in case the int value is too big to fit >>into 32 bits. >>After that it's up to the user to decide what to do -> cast to float or >>use bcmath . > >That will probably work for returning field values in a result set, the >particular problem I am looking at is a function that is defined as >returning an integer, but which could potentially contain a 64 bit value. > >Is any work being done on handling THAT potential time bomb?
You could use a 64bit machine :) Andi

Lester Caine

22 years ago
Andi Gutmans wrote:
> At 09:03 PM 4/17/2004 +0100, Lester Caine wrote: > >>> AFAIK ext/mysqli returns string in case the int value is too big to >>> fit into 32 bits. >>> After that it's up to the user to decide what to do -> cast to float >>> or use bcmath . >> >> That will probably work for returning field values in a result set, >> the particular problem I am looking at is a function that is defined >> as returning an integer, but which could potentially contain a 64 bit >> value. >> >> Is any work being done on handling THAT potential time bomb? > > You could use a 64bit machine :)
That is probably what Firebird will be running on later this year, but the PHP servers are likely to be 32 bit for some time. In any case, the customer sites still insist on Windoze because their IT departments don't understand anything else ;) So 32bit is the order of the day when deploying - unless someone has a 64bit version of Windoze - but then the IT departments would want years to test it :)
-- Lester Caine ----------------------------- L.S.Caine Electronic Services

Ard Biesheuvel

22 years ago
Lester Caine wrote:
> An interesting little question has pooped up. > > How big is an integer? > > Firebird uses BIGINT or INT_64 for generator values, and the new > ibase_gen_id in PHP5 returns that value as an integer. > > Has any thought been given to managing 64bit field values in PHP5? >
Actually, this 'time bomb' has already been handled. If the generated value doesn't fit in a long, it will return a string. So on a 64-bit machine, this will never occur. On a 32-bit machine, the returned type of ibase_gen_id() will suddenly start returning strings. Please note that this is consistent with the behaviour of other ibase_*() functions that handle BIGINTs.
-- Ard