[RFC] Integer Semantics

Kris Craig

12 years ago

On Tue, Aug 19, 2014 at 3:36 PM, Andrea Faulds <ajf@ajf.me> wrote:

> 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/
>
>
>
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

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

Laruence

12 years ago

Hey:

On Wed, Aug 20, 2014 at 6:36 AM, Andrea Faulds <ajf@ajf.me> wrote:

> 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/
>
>
>
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>

--
Laruence  Xinchen Hui
http://www.laruence.com/

Andrew Faulds

12 years ago

On 20 Aug 2014, at 03:53, Laruence <laruence@php.net> wrote:

> On Wed, Aug 20, 2014 at 6:36 AM, Andrea Faulds <ajf@ajf.me> wrote:
>> 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.

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/

Pierre Joye

12 years ago

On Wed, Aug 20, 2014 at 11:24 AM, Andrea Faulds <ajf@ajf.me> wrote:

>
> On 20 Aug 2014, at 03:53, Laruence <laruence@php.net> wrote:
>
>> On Wed, Aug 20, 2014 at 6:36 AM, Andrea Faulds <ajf@ajf.me> wrote:
>>> 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.
>
> 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

Derick Rethans

12 years ago

On Wed, 20 Aug 2014, Andrea Faulds wrote:

>
> On 20 Aug 2014, at 03:53, Laruence <laruence@php.net> wrote:
>
> > On Wed, Aug 20, 2014 at 6:36 AM, Andrea Faulds <ajf@ajf.me> wrote:
> >> 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.
>
> 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

Andrew Faulds

12 years ago

On 22 Aug 2014, at 12:36, Derick Rethans <derick@php.net> wrote:

> 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/

Sara Golemon

12 years ago

On Tue, Aug 19, 2014 at 3:36 PM, Andrea Faulds <ajf@ajf.me> wrote:

> 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

Dmitry Stogov

12 years ago

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.

On Wed, Aug 20, 2014 at 8:05 AM, Sara Golemon <pollita@php.net> wrote:

Andrew Faulds

12 years ago

On 20 Aug 2014, at 06:52, Dmitry Stogov <dmitry@zend.com> wrote:

> 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/

Dmitry Stogov

12 years ago

On Wed, Aug 20, 2014 at 1:20 PM, Andrea Faulds <ajf@ajf.me> wrote:

>
> On 20 Aug 2014, at 06:52, Dmitry Stogov <dmitry@zend.com> wrote:
>
> > 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)
>

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.

Derick Rethans

12 years ago

On Tue, 19 Aug 2014, Andrea Faulds wrote:

> 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