We definitely need to start thinking forward and introduct a 64-bit type. It needn't replace the 32-bit type.
IIRC, Andi promised that we would have this after 5.1, so I think it's a done deal. It's especially important now that we have a number of extensions returning 64-bit data. And with Visual Studio .Net 2005, time_t is now 64-bit (!?) --Wez. On 8/12/05, Sara Golemon <[EMAIL PROTECTED]> wrote: > > How about doubling integer precision to 64 bits and float/double precision > > to 128 bits? It's in line with 64 bit CPU capabilities, and personally, I > > wouldn't mind it a bit if it would make numerical processing in PHP slower > > on 32 bit systems. I think the advantages are much too great for that. If > > this is ever gonna happen, I think PHP6 would be great timing for it. > > > If there were such a type as 'zend_long' used universally that might be at > least possible (even configurable as a compile-time switch), but as it is > *EVERYTHING* that touches a zval expects a long. On 32bit platforms that's > a 32-bit number and there's no trivial way to change that. > > Athlon64s and Opterons are cheap nowadays anyway. I picked up a MB/CPU > combo at Fry's last week for like $200. > > -Sara > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
