From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | pgsql-committers(at)postgresql(dot)org |
Subject: | Re: pgsql: Use new overflow aware integer operations. |
Date: | 2017-12-22 16:00:54 |
Message-ID: | 18169.1513958454@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-committers |
Andres Freund <andres(at)anarazel(dot)de> writes:
> Use new overflow aware integer operations.
I just tried to compile manually on prairiedog for the first time since
this went in, and noticed that it now produces a boatload of warnings
like
int.c: In function 'int2pl':
int.c:735: warning: 'result' may be used uninitialized in this function
I think it's entirely within its rights to complain, because
the non-builtin code paths in int.h look like
int32 res = (int32) a + (int32) b;
if (res > PG_INT16_MAX || res < PG_INT16_MIN)
return true;
*result = (int16) res;
return false;
and so if an overflow occurs then *result won't get set.
I do not think it is reasonable for these functions to not set the
output variable at all in the overflow case; it is not their job
to opine on whether the caller may use the result. Furthermore,
this is an incorrect emulation of the built-in functions;
the gcc manual clearly says
These built-in functions promote the first two operands into
infinite precision signed type and perform addition on those
promoted operands. The result is then cast to the type the third
pointer argument points to and stored there. If the stored result
is equal to the infinite precision result, the built-in functions
return false, otherwise they return true.
So as coded, there is a difference of behavior depending on whether
you have the built-in, and that cannot be anything but bad.
Therefore I think all of these need a patch like
int32 res = (int32) a + (int32) b;
+ *result = (int16) res;
if (res > PG_INT16_MAX || res < PG_INT16_MIN)
return true;
- *result = (int16) res;
return false;
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2017-12-22 16:24:19 | Re: pgsql: Get rid of copy_partition_key |
Previous Message | Teodor Sigaev | 2017-12-22 10:33:42 | pgsql: Add optional compression method to SP-GiST |