| From: | Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com> |
|---|---|
| To: | Vik Fearing <vik(dot)fearing(at)2ndquadrant(dot)com> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>, Stephen Frost <sfrost(at)snowman(dot)net>, Chapman Flack <chap(at)anastigmatix(dot)net>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Greatest Common Divisor |
| Date: | 2020-01-25 14:18:33 |
| Message-ID: | CAEZATCUHRL5W=ZQubNcavPLky4o5eXNWRvD_JSN2zOL-nf7seA@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Mon, 20 Jan 2020 at 08:04, Vik Fearing <vik(dot)fearing(at)2ndquadrant(dot)com> wrote:
>
> On 20/01/2020 08:44, Dean Rasheed wrote:
> >>
> > I see this has been marked RFC. I'll take it,
>
Committed with some adjustments, mostly cosmetic but a couple more substantive:
The code to guard against a floating point exception with inputs of
(INT_MIN, -1) wasn't quite right because it actually just moved the
problem so that it would fall over with inputs of (INT_MIN, +1).
The convention in numeric.c is that the xxx_var() functions take
*pointers* to their NumericVar arguments rather than copies, and they
do not modify their inputs, as indicated by the use of "const". You
might just have gotten away with what you were doing, but I think it
was bad style and potentially unsafe -- for example, someone calling
gcd_var() with a NumericVar that came from some other computation and
having a non-null buf would risk having the buf freed in the copy,
leaving the original NumericVar with a buf pointing to freed memory.
Regards,
Dean
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Magnus Hagander | 2020-01-25 14:43:41 | Re: pg_stat_bgwriter.buffers_backend is pretty meaningless (and more?) |
| Previous Message | Dent John | 2020-01-25 10:59:24 | Re: [WIP] UNNEST(REFCURSOR): allowing SELECT to consume data from a REFCURSOR |