From: | Greg Stark <gsstark(at)mit(dot)edu> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Neil Conway <neil(dot)conway(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Compiling CVS HEAD with clang under OSX |
Date: | 2010-08-02 16:34:57 |
Message-ID: | AANLkTikk6NUhW_A88sO=gOWtYxQkLTGn+yPZcb5oL9Ja@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Aug 2, 2010 at 4:27 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Yeb Havinga | 2010-08-02 18:56:48 | Re: patch for check constraints using multiple inheritance |
Previous Message | Robert Haas | 2010-08-02 16:27:46 | Re: (9.1) btree_gist support for searching on "not equals" |