Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:42927 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 9637 invoked from network); 5 Feb 2009 09:36:56 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 5 Feb 2009 09:36:56 -0000 X-Host-Fingerprint: 195.212.29.92 blueice4n2.uk.ibm.com Received: from [195.212.29.92] ([195.212.29.92:11640] helo=localhost.localdomain) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 7D/CE-24530-733BA894 for ; Thu, 05 Feb 2009 04:36:55 -0500 To: internals@lists.php.net Message-ID: <498AB32A.3030003@uk.ibm.com> Date: Thu, 05 Feb 2009 09:36:42 +0000 User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 CC: internals@lists.php.net References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Posted-By: 195.212.29.92 Subject: Re: [PHP-DEV] casting doubles to ints From: ilewis@uk.ibm.com (Iain Lewis) On windows x86_64, PHP_INT_MAX is 2147483647. This is because in the underlying c-code, a long is 32 bit. However, linux on x86_64 uses a 64bit long so PHP_INT_MAX is going to be 9223372036854775807. Kenan R Sulayman wrote: > Hi Lain! > > As much as I did understand, this might be a pretty good idea. > Anyhow, you want to make this variable to be constant? > > I think, this might break some calculations.- > > And another question: > Does anyone knows, why PHP is showing 2147483647 as PHP_INT_MAX ? *truly, > I'm running x64* > > Thanks, > -- > (c) Kenan Sulayman > Freelance Designer and Programmer > > Life's Live Poetry > > > 2009/2/4 Iain Lewis > >> Hello all, >> >> I wanted to suggest back porting the behaviour of the DVAL_TO_LVAL macro >> from zend_operators.h from 5.3 to 5.2, and wondered whether people thought >> this was a good idea or not? >> >> The reason I want to do this is that while writing some tests, I noticed >> that the behaviour of casting a float to an int is a bit counter-intuitive >> on 64bit platforms for PHP 5.2. It looks as though this has been fixed in >> 5.3, and it would seem like a good idea to put this change back to 5.2 as >> well. From a personal point of view, it would mean I could write one test >> that would work on both 5.2 and 5.3, but it also seems like a sensible >> change, as the current behaviour is non-obvious. The change would cause some >> current tests to break, but I am happy to do the work to fix those up. >> >> This is how a few expressions get evaluated at the moment. Changing the >> macro would make the 5.2 behaviour match 5.3 >> >> Expression 5.3 (RHEL5-64) 5.2 (RHEL5-64) >> >> (int) (PHP_INT_MAX) 9223372036854775807 9223372036854775807 >> (int) (PHP_INT_MAX + 1) 9223372036854775807 -9223372036854775808 >> (int) (PHP_INT_MAX + 1000) 9223372036854775807 -9223372036854775808 >> (int) (PHP_INT_MAX + 10000) 9223372036854775807 -9223372036854765568 >> >> Does this seem like a good change? >> >> -- >> PHP Internals - PHP Runtime Development Mailing List >> To unsubscribe, visit: http://www.php.net/unsub.php >> >> >