From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-committers(at)postgresql(dot)org |
Subject: | Re: pgsql: Use new overflow aware integer operations. |
Date: | 2018-02-14 22:30:26 |
Message-ID: | 20180214223026.m2alym4qrdnimqrd@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-committers |
On 2017-12-29 12:21:54 -0800, Andres Freund wrote:
> On 2017-12-27 17:59:26 -0500, Tom Lane wrote:
> > #if defined(HAVE__BUILTIN_OP_OVERFLOW)
> > return __builtin_add_overflow(a, b, result);
> > #else
> > int32 res = (int32) a + (int32) b;
> >
> > if (res > PG_INT16_MAX || res < PG_INT16_MIN)
> > + {
> > + *result = 0; /* just to keep compiler quiet */
> > return true;
> > + }
> > *result = (int16) res;
> > return false;
> > #endif
> >
> > I do not think this would cause any performance loss in our expected
> > usage, because reasonably bright compilers would detect that the store
> > is dead code and remove it. But less-bright compilers would not be
> > issuing warnings.
>
> Yea, that works for me. I wonder if we should choose an absurd sentinel
> value to prevent code from relying on one? 0x0000beef or such. Unless
> somebody protests soon-ish I'll make it so.
Pushed that way (with 0x5EED as the value, seems more appropriate ;)).
I can't convince any of my compilers to actual emit warnings in this
case, so we'll have to see whether prairiedog like this...
Greetings,
Andres Freund
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2018-02-14 22:36:38 | Re: pgsql: Use new overflow aware integer operations. |
Previous Message | Andres Freund | 2018-02-14 22:30:24 | pgsql: Return implementation defined value if pg_$op_s$bit_overflow ove |