# [RFC] Integer Semantics - Thread: https://externals.io/message/76710 - Original archive: https://news-web.php.net/php.internals/76710 - Started by Andrea Faulds on 2014-08-19T22:36:55+00:00 - Messages: 12 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #76710 — Andrea Faulds — 2014-08-19T22:36:55+00:00 URL: https://externals.io/message/76710#76710 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/ --- ## #76711 — Kris Craig — 2014-08-20T01:54:29+00:00 URL: https://externals.io/message/76710#76711 · In reply to: #76710 > 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 --- ## #76713 — Laruence — 2014-08-20T02:53:50+00:00 URL: https://externals.io/message/76710#76713 · In reply to: #76710 Hey: > 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 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/ --- ## #76714 — Sara Golemon — 2014-08-20T04:05:39+00:00 URL: https://externals.io/message/76710#76714 · In reply to: #76710 > https://wiki.php.net/rfc/integer_semantics > 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 --- ## #76716 — Dmitry Stogov — 2014-08-20T05:52:03+00:00 URL: https://externals.io/message/76710#76716 · In reply to: #76714 1) `INF` conversion to zero seems wrong. May be +INF should be converted to MAX_LONG and -INF to MIN_LONG? 2) Negative shifts would be useful, as Sara mentioned. 3) 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 --- ## #76721 — Andrea Faulds — 2014-08-20T09:20:20+00:00 URL: https://externals.io/message/76710#76721 · In reply to: #76716 > 1) `INF` conversion 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. > 3) 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/ --- ## #76723 — Andrea Faulds — 2014-08-20T09:24:01+00:00 URL: https://externals.io/message/76710#76723 · In reply to: #76713 > > > […] > > 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/ --- ## #76725 — Pierre Joye — 2014-08-20T09:59:49+00:00 URL: https://externals.io/message/76710#76725 · In reply to: #76723 > > > > > […] > > 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 --- ## #76726 — Dmitry Stogov — 2014-08-20T10:05:46+00:00 URL: https://externals.io/message/76710#76726 · In reply to: #76721 > > > > > […] > 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. > > > […] > 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/ --- ## #76752 — Derick Rethans — 2014-08-21T10:11:19+00:00 URL: https://externals.io/message/76710#76752 · In reply to: #76710 > 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 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 --- ## #76800 — Derick Rethans — 2014-08-22T11:36:40+00:00 URL: https://externals.io/message/76710#76800 · In reply to: #76723 > > > > > […] > > 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 --- ## #76922 — Andrea Faulds — 2014-08-28T15:44:59+00:00 URL: https://externals.io/message/76710#76922 · In reply to: #76800 > 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/