Re: [STANDARDS] Integer operations are implementation-defined

On 8 Aug 2014, at 08:27, Drew Paroski <[email protected]> wrote:

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

The problem is people can and do rely on implementation-defined behaviour, and the more high-level a language is, the less undefined or platform-dependant it ought to be. It is difficult to write correct, portable code if every implementation and platform does a completely different thing.

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

Although it’s a shame, for 32-bit applications you may have to (or unintentionally) rely on it, unfortunately, as allowing overflow to float gives you 20 more bits of integer precision if floats are 64-bit IEEE 754 double-precision (which they usually are).

> 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),

Well, there is the constant. Beyond PHP_INT_MAX, it’ll overflow. In PHP.net it is very well defined.

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

To write correct programs you need to handle the overflow case somehow, and at least if we just do one thing, there’s only one behaviour you need to account for.

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

Of course, because it’s an edge case. Most of the time, nothing breaks. It’s the uncommon cases where things will horribly break here.

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

Allowing things to be implementation-defined can help performance, but I don’t think it’s a good idea. Flexibility is something C has, and it has meant that it is very, very difficult to write portable code that does the same thing across platforms and implementations.  If people want really high performance, they can use C and sacrifice easy portability. However, I don’t think PHP needs to be C. PHP is a language for web requests. Integer overflow to float introduces only a tiny overhead and isn’t really a big performance issue. It is things like blocking I/O and waiting for databases that really slow down PHP apps. I don’t think we should veer down the path of sacrificing our cross-platform guarantees because it provides a very minor performance conveniance.

Let’s write that horrible C code at the engine level to implement PHP, rather than forcing users to deal with implementation idiosyncrasies when their applications hit an edge case.

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

Thanks for sending your thoughts.

If I might say it again, while PHP.net’s behaviour here is far from ideal, I think it’s still much better than just wrapping around. It changes type, but most of the information is preserved (sign, leading digits, magnitude). If your number wraps around on overflow, all information is lost, and it’s not even obvious anything went wrong. Basically, for naïvely-written apps, the PHP.net behaviour will break them least and is the most intuitive. It’s far from perfect and I’d love to use bigints or something, but until that happens, I’d much rather overflow to float.

Thanks!
--
Andrea Faulds
http://ajf.me/