Good evening,
I have made an RFC which would make some small changes to how integers are handled, targeted at PHP 7:
https://wiki.php.net/rfc/integer_semantics
Thoughts and questions are appreciated. Thanks!
Andrea Faulds
http://ajf.me/
Good evening,
I have made an RFC which would make some small changes to how integers are
handled, targeted at PHP 7:https://wiki.php.net/rfc/integer_semantics
Thoughts and questions are appreciated. Thanks!
Andrea Faulds
http://ajf.me/--
Makes sense to me. I was a little uneasy at first, but you made a very
good point that a high-level language like PHP should be abstracting such
environment-dependent differences away. And since you're targetting the
next major release, BC isn't an issue.
--Kris
Hey:
Good evening,
I have made an RFC which would make some small changes to how integers are handled, targeted at PHP 7:
I'd like don't change the works behavior. make it act the similar as C does.
thanks
Thoughts and questions are appreciated. Thanks!
Andrea Faulds
http://ajf.me/--
--
Laruence Xinchen Hui
http://www.laruence.com/
Good evening,
I have made an RFC which would make some small changes to how integers are handled, targeted at PHP 7:
I'd like don't change the works behavior. make it act the similar as C does.
For some of these things the behaviour is explicitly undefined in C, meaning it’s dangerous for us not to handle them specially, as undefined behaviour seems to give compilers an unlimited license to do absolutely anything at all.
The rest are “implementation-defined”. While what C does “works”, I’d rather we do one thing consistently instead of forcing developers to deal with the kinds of platform and compiler differences tools like PHP should be abstracting.
Andrea Faulds
http://ajf.me/
Good evening,
I have made an RFC which would make some small changes to how integers are handled, targeted at PHP 7:
I'd like don't change the works behavior. make it act the similar as C does.
For some of these things the behaviour is explicitly undefined in C, meaning it’s dangerous for us not to handle them specially, as undefined behaviour seems to give compilers an unlimited license to do absolutely anything at all.
The rest are “implementation-defined”. While what C does “works”, I’d rather we do one thing consistently instead of forcing developers to deal with the kinds of platform and compiler differences tools like PHP should be abstracting.
I totally agree with Andrea here. While it made sense to map C
behavior for years, for many of us, as we all came from a C backgroud.
However it makes less and less sense lately, if at all.
Cheers,
Pierre
@pierrejoye | http://www.libgd.org
Good evening,
I have made an RFC which would make some small changes to how
integers are handled, targeted at PHP 7:I'd like don't change the works behavior. make it act the similar
as C does.For some of these things the behaviour is explicitly undefined in C,
meaning it’s dangerous for us not to handle them specially, as
undefined behaviour seems to give compilers an unlimited license to do
absolutely anything at all.
Although I think it is good to make it work the same on every platform,
I do think that changing it to match what the most used compiler (GCC)
on our most used platform (Linux/AMD64) is what the new behaviour should
be like — not something that "looks best". I think that's what Laruence
was trying to say as well.
It causes the least amount of BC breaks for our users.
cheers,
Derick
Although I think it is good to make it work the same on every platform,
I do think that changing it to match what the most used compiler (GCC)
on our most used platform (Linux/AMD64) is what the new behaviour should
be like — not something that "looks best". I think that's what Laruence
was trying to say as well.It causes the least amount of BC breaks for our users.
That would also be a possibility. It’s not my favourite behaviour, but it’d at least be consistent.
However, I wonder how many applications rely on the current behaviour on AMD64. It’s not terribly intuitive. For example, a shift by a negative number works like this on AMD64:
$op1 << ((PHP_INT_MAX + $op2) % 64)
So, for example, were I to make $op2 be -1:
$op1 << ((PHP_INT_MAX + $op2) % 64)
$op1 << ((PHP_INT_MAX - 1) % 64)
$op1 << (9223372036854775806 % 64)
$op1 << 62
Which is probably not what the user was expecting.
Actually, I kinda lied, that’s just what sane compilers would do on AMD64. Negative bit shifts are undefined behaviour in the C standard, which gives the compiler an unlimited license to do absolutely anything it wants, including, for example, to not execute the shift altogether and assume it is dead code. In practise this is unlikely, however that is the standard.
You make a good point that this is a BC break, though. This RFC in itself doesn’t make a super-compelling case, given it doesn’t really introduce any benefits (aside from the fact you can rely on $x >> $y, where $y >= 64, equalling zero). It might be better if I retracted this RFC and kept these changes to the bigint RFC.
--
Andrea Faulds
http://ajf.me/
In a perfect world, I'd rather see "<< -X" be equivalent to ">> X",
but since we do something very different currently, I think your
approach of throw an error and ask questions later seems appropriate.
The other ones all sound inarguable.
+1
-Sara
-
INFconversion to zero seems wrong. May be +INF should be converted to
MAX_LONG and -INF to MIN_LONG? -
Negative shifts would be useful, as Sara mentioned.
-
a bit unrelated, but it also may make sense to introduce a logical right
shift operator (>>> in Java)
the rest seems fine, patch looks OK.
Thanks. Dmitry.
In a perfect world, I'd rather see "<< -X" be equivalent to ">> X",
but since we do something very different currently, I think your
approach of throw an error and ask questions later seems appropriate.
The other ones all sound inarguable.+1
-Sara
INFconversion to zero seems wrong. May be +INF should be converted to MAX_LONG and -INF to MIN_LONG?
I think of Infinity as more of an error value than an actual number. Not using MAX_LONG and MIN_LONG means it casts to the same value matter how large the integer type is, and it happens to be what JavaScript casts Infinity to. There’s also the fringe benefit that 1/0’s result in PHP, FALSE, casts to zero, as Infinity now would also, which is the standard IEEE 754 result for 1/0.
- a bit unrelated, but it also may make sense to introduce a logical right shift operator (>>> in Java)
How would that function?
Andrea Faulds
http://ajf.me/
INFconversion to zero seems wrong. May be +INF should be converted
to MAX_LONG and -INF to MIN_LONG?I think of Infinity as more of an error value than an actual number. Not
using MAX_LONG and MIN_LONG means it casts to the same value matter how
large the integer type is, and it happens to be what JavaScript casts
Infinity to. There’s also the fringe benefit that 1/0’s result in PHP,
FALSE, casts to zero, as Infinity now would also, which is the standard
IEEE 754 result for 1/0.
- a bit unrelated, but it also may make sense to introduce a logical
right shift operator (>>> in Java)
The difference between "arithmetic" and "logical" shift is sign propagation.
0x10000000 >> 1 == 0x11000000
0x10000000 >>> 1 == 0x01000000
In C the same >> operator perform "arithmetic" shift for signed numbers and
"logical" shift for unsigned.
Thanks. Dmitry.
How would that function?
Andrea Faulds
http://ajf.me/
Good evening,
I have made an RFC which would make some small changes to how integers are handled, targeted at PHP 7:
I think it is good to make sure it behaves the same on all systems.
However, I think the behaviour should become what currently is the shift
behaviour on the platform with our largest userbase: Linux on AMD64 with
GCC.
There is no reason to penalise people that well might have relied on
some "odd" behaviour - possible even with good reasons.
cheers,
Derick