casting doubles to ints

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

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 ilewis@uk.ibm.com

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?