Dean Rasheed <dean.a.rash...@gmail.com> writes:
> On 24 November 2015 at 16:20, Tom Lane <t...@sss.pgh.pa.us> wrote:
>> ... None of these effects are going to let the final div[qi+1] value
>> get to more than two or three times NBASE squared, which is still
>> an order of magnitude less than INT_MAX.
> Right. In fact I think div[qi+1] is even more constrained than that (see
> below).
Thanks for the additional analysis and testing.
>> I think all this deserves some code comments, but I'm not sure whether
>> we need to bother with casting to int64. Thoughts?
> I think probably just a comment is OK.
I'm inclined to agree. The only reason I'd worry at all is that the
compiler guys are getting ever more aggressive about claiming that any
integer overflow can result in arbitrarily-broken behavior. However,
we already have a lot of other code that depends on -fwrapv or equivalent
overflow behavior, so I doubt that this is the first place to worry
about it. The underlying hardware is certainly going to behave as we
wish, and it's pretty hard to see how a compiler could "optimize" the
assembly code in a way that would break such a simple calculation.
I'll go add some comments and call it good.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
