Skip site navigation (1) Skip section navigation (2)

Re: BUG #5416: int4inc() is wrong

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "John Regehr" <regehr(at)cs(dot)utah(dot)edu>
Cc: pgsql-bugs(at)postgresql(dot)org
Subject: Re: BUG #5416: int4inc() is wrong
Date: 2010-04-13 17:49:36
Message-ID: 7116.1271180976@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-bugs
"John Regehr" <regehr(at)cs(dot)utah(dot)edu> writes:
> The overflow check in int4inc() from int.c is wrong.

Hm, works for me:

regression=# \set VERBOSITY verbose
regression=# select int4inc(2147483647);
ERROR:  22003: integer out of range
LOCATION:  int4inc, int.c:768

> The problem is that in
> C, signed overflow is undefined.  Both LLVM and GCC eliminate the overflow
> check in this function.  This is easy to see by looking at the asm emitted
> by either compiler.

Note that we recommend using -fwrapv with gcc, so that it doesn't break
code that depends on this type of test.  (If int4inc isn't working then
there are probably a lot of other places that are broken too.)  I imagine
LLVM has the same or similar switch.

> There are several easy ways to fix this code.  One would be to test arg
> against INT_MAX before incrementing.  Another would be to cast arg to
> unsigned, increment it, then do the check.

None of these proposals are improvements over what's there.  The
fundamental problem is that if the compiler chooses to believe that
overflow doesn't exist, it can optimize away *any* test that could only
succeed in overflow cases.  Finding a form of the test that fails to be
optimized away by today's version of gcc doesn't protect you against
tomorrow's version.

			regards, tom lane

In response to

Responses

pgsql-bugs by date

Next:From: Alvaro HerreraDate: 2010-04-13 19:28:33
Subject: Re: BUG #5418: psql exits after using tab-completion with error message
Previous:From: Ben MadinDate: 2010-04-13 13:16:49
Subject: Re: BUG #5418: psql exits after using tab-completion with error message

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group