Re: [STANDARDS] Integer operations are implementation-defined

Andrea,

Hi there! I've been working on HHVM for a bit and am just catching up on this
thread. I wanted to reply to some of the points that you brought up.

On Wed, Jul 30, 2014 at 11:29 AM, Andrea Faulds <[email protected]> wrote:

> The specification is supposedly based off php.net PHP 5.6, as far as I know.

While one of the goals of the spec is to describe semantics that php.net PHP
5.6 is completely compatible with (given that php.net PHP is the oldest and
most used implementation of PHP), I'd argue it is not an explicit goal of the
spec to precisely describe every behavior of php.net PHP down to the last
detail.

> By allowing implementations to wrap around rather than promote to float, we
> are making sure PHP code cannot be written as “write-once, run anywhere” as
> it may have completely different results on two different implementations.

Pursuant to my first point above, I wanted to push back on the potential
implication here that all implementations should agree on everything. Some
corners of a programming language can be implementation-defined, and
programmers should be advised to stay away from these parts if they want their
code to be portable across implementations.

Ideally there shouldn't be many corners like this and such corners should all
be things that programmers should avoid anyway because they are bad practice.
IMHO relying on how integer overflow works in PHP is bad practice, and for a
number of use cases it's difficult to write correct code that relies on how
int->float conversion works in php.net PHP.

https://wiki.php.net/rfc/bigint does a great job of summarizing how int->float
promotion is messy and problematic. The programmer can't always assume that
int->float promotion will happen at a hardcoded limit (because of differences
between 32-bit and 64-bit systems), nor can they be sure what precision they
will get from floats because "the size of a float is platform-dependent"
according to http://php.net/manual/en/language.types.float.php . Also, floats
behave differently than ints when used as array keys and in some type-juggling
or type-casting situations, so for a number of use cases promoting an int to a
float ends up quickly leading to the PHP program misbehaving. To me, this
issue comes down to whether integer overflow is one of those corners of the
language that's bad practice to rely on.

> it might make writing a JIT slightly easier and it might be nicer for
> performance

Yes and yes. I'd argue that this isn't just a concern for HHVM, it's also a
concern for PHPNG and any other PHP engine that wants to make use of type
inference and analysis techniques to deliver improved performance. As Sara
Golemon noted, HHVM matches php.net PHP behavior on this issue by default.
However, matching this behavior did hurt performance a bit and it feels like a
shame because as far as I can tell >99% of PHP code out in the wild does not
seem to depend on how integer overflow works in practice. Before HHVM was
changed to do int->float promotion, we were surprised by the wide range of PHP
applications that HHVM was able to run correctly without matching php.net PHP
on this issue.

> I should clarify I wish no ill-will towards the HHVM team. The work they are
> doing is amazing and it is great to see competition. However, I believe
> strongly that PHP should be consistent across implementations and platforms as
> much as possible. Doing the right thing might be inconvenient, but it would
> mean less fragmentation and actually give the spec more meaning as we can
> standardise on a single behaviour.

I share your optimism about the broader PHP community and the HHVM project
working well together. Regardless of how this specific issue is resolved, I
wanted to express the other side of the broader specificity debate and say that
there are arguably some cases where it makes sense to make things
implementation-defined to give engine writers enough freedom and flexibility to
build faster implementations for a wide range of platforms.

When the spec was being drafted it felt like integer overflow wasn't important
to the vast majority of PHP applications (from HHVM's experience running apps)
and that php.net's current scheme was fairly clunky (as Sara noted regarding
the existence of the bigint RFC), so it didn't feel compelling to make the spec
require all implementations to match php.net's integer overflow behavior at
this time. I hope this feedback finds you well and am interested to hear more
of your thoughts on this.

-Drew Paroski