On Mon, Aug 2, 2010 at 4:27 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Here's the problem: if the compiler is allowed to assume that overflow > cannot happen, it is always going to be able to "prove" that the > if-test is constant false. This is inherent. Anybody claiming to > exhibit a safe way to code the overflow test is really only telling > you that today's version of their compiler isn't smart enough to make > the proof.
So I'll do the next two parts of the dialogue myself: Questioner: So why not write that as: if ((arg1 > 0 && arg2 > 0 && arg1 > MAXINT - arg2) || (arg1 < 0 && arg2 < 0 && arg1 < MININT + arg2)) elog("overflow") else return arg1+arg2; Tom: Because that code is much more complex and prone to errors especially when you start getting into multiplication and other operations and it's also much slower than the code which allows overflow to happen and then checks that the result makes sense. I'm not entirely sure I agree. At least I haven't actually gone through all the arithmetic operations and I'm not sure how much more complex they get. If they were all at that level of complexity I think I would say we should go ahead and bite the performance bullet and do it the ultra-safe way. -- greg -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers