Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:42929
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Message-ID: <BE.00.24530.EC8BA894@pb1.pair.com>
To: internals@lists.php.net
Date: Thu, 05 Feb 2009 10:00:33 +0000
User-Agent: Thunderbird 2.0.0.19 (Windows/20081209)
MIME-Version: 1.0
References: <CA.32.61634.A22C9894@pb1.pair.com> <00fd01c986ee$7d94ec20$0201a8c0@PC>
In-Reply-To: <00fd01c986ee$7d94ec20$0201a8c0@PC>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] casting doubles to ints
From: ilewis@uk.ibm.com (Iain Lewis)

5.2 32bit situation at the moment

(int)(PHP_INT_MAX +1) < (int)(PHP_INT_MAX +100) < (int)(PHP_INT_MAX + 1000)

This does seem pretty sensible. I'm more worried about the 64bit case where:

(int)(PHP_INT_MAX +1) == (int)(PHP_INT_MAX +100) < (int)(PHP_INT_MAX + 1000)

It would be nice for the 64 bit behaviour to be at least predictable, 
and the 5.3 code seems to do that.

Matt Wilmas wrote:
> Hi Iain,
> 
> (Yes, this subject has me sending a message to the list again instead of
> lurking, and I should be back with some internals stuff again soon, hehe.
> :^))
> 
> ----- Original Message -----
> From: "Iain Lewis"
> Sent: Wednesday, February 04, 2009
> Subject: [PHP-DEV] casting doubles to ints
> 
>> 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.
> 
> NOOOO, please. :-)  In fact, I thought maybe your message was complaining
> about the 5.3 changes.  I was suggesting reverting 5.3 to 5.2's behavior at
> the very least -- see my "DVAL_TO_LVAL() change, different behavior" thread
> [1] from last year for the reasons.  It breaks long-time behavior
> (overflow-wise), and isn't even consistent with how it works.  I was
> thinking there will be some breakage, bug reports, etc. as 5.3 is used more,
> if others are doing stuff like my examples showed. *shrug*
> 
> In addition to my suggestion of going back to the behavior of 5.2 and
> earlier, I think DVAL_TO_LVAL() can be updated to ensure consistent,
> reliable overflow behavior on all systems -- it seems like it has been on
> the majority, but a simple (long) cast of the double (when out of range) in
> C is implementation-defined, so depending...  Anyway, I didn't get to test
> my idea yet, but will get to it soon!
> 
> The thing that I think was originally trying to be fixed (large function
> args) can be done easily in zend_parse_parameters() for those desired use
> cases.
> 
> [1] http://marc.info/?t=120799728700001&r=1&w=2
> 
>> 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?
> 
> 
> - Matt
>