On 15 Jul 2014, at 08:06, Lester Caine <les...@lsces.co.uk> wrote: > Taking this in isolation is wrong ... > It is essentially linked up with all of the discussion on '64bit' > processing. What seems to be ignored so far is the simple 'bigint' > value. Limiting 32 bit systems to only support 32 bit integers may be > the easy solution, but bigint is an essential element of most database > type sets these days, so should be supported transparently. If a primary > key is provided as part of a database result set, then do we really want > the situation where some installs fall over with an overflow of that key > on 32 bit systems? Having to use a secondary level function exclusively > simply because the core processing gets it wrong is another mistake? > > Certainly it's not going to be easy to handle, and may not even be > practical? But even the discussion on 'type hinting' seems to ignore the > range problem where a 64bit value may be required but the installation > on4y supports 32bit integers. Currently the value simply works with the > string version …
Yeah, hence why I’m also proposing the bigint RFC, which intdiv() would work nicely with. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
