Re: Integer operations are implementation-defined

On 30 Jul 2014, at 19:59, Sara Golemon <pollita@php.net> wrote: > On Wed, Jul 30, 2014 at 11:29 AM, Andrea Faulds <ajf@ajf.me> wrote: >>> * The computation is done as though the types of the values were float with the result >>> having that type >>> * The result type is int and the value reflects wrap-around (for example adding 1 to >>> the largest value results in the smallest value) >>> * The computation is done as though the type had some unspecified, arithmetic-like >>> object type with the result being mathematically correct >> >> I really don’t like this. >> > Found that one quicker than I expected. :) Side note: HHVM actually > does the same behavior as PHP by default. We only do the wrap-around > behavior when in "Hack" mode (which isn't PHP, so that's fine). Yeah, I know about that now. Apparently you guys finally fixed it. :) > For what it's worth, I think both of the first two options do the user > a disservice with their behaviors. Wrap-around is probably not what > you're expecting, but float promotion loses precision (immediately, on > 64bit platforms) and that produces bugs which are even harder to spot > (at least when it's negative, it's pretty obvious where something went > wrong). Oh sure. I’d much rather have arbitrary-precision ints, but even without them, we should pick one mode and stick with it. > >> Of course, integer size will inevitably vary (unless my bigints RFC makes it in ;) >> > Actually, it's this RFC, and the 64-bit/float issue (which isn't a new > idea on internals@) which led to the 3rd behavior option. Personally, > I'd love to see both implementations move that way. What, the bigints RFC? In the case of bigints, the plan is just to define integers to be of arbitrary size but with a note that implementations *may* use a native type internally and switch to an internal bigint type on overflow (as my implementation does and I expect HHVM and others would), so long as they’re completely indistinguishable to userland. That would actually mean you wouldn’t define an overflow case at all. You do, however, have the fun case of having to throw some sort of error if you do a calculation with a result too large to fit in memory (either hitting the memory limit, or needing to allocate more than size_t bytes would cause an error, as my patch does). > Ultimately, option#2 was left in because it's used by a few > implementations (not just HHVM) and it was worth mentioning. If it > was pulled out of the spec, I wouldn't personally be bothered. > > As for option#3, that was perhaps optimistic. Maybe pull it out and > replace it when your RFC passed. :) I say pull both and just leave in #1. :) -- Andrea Faulds http://ajf.me/