From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Vitaly Burovoy <vitaly(dot)burovoy(at)gmail(dot)com> |
Cc: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Julien Rouhaud <julien(dot)rouhaud(at)dalibo(dot)com>, Craig Ringer <craig(at)2ndquadrant(dot)com>, Haribabu Kommi <kommi(dot)haribabu(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: macaddr 64 bit (EUI-64) datatype support |
Date: | 2016-10-12 20:52:07 |
Message-ID: | 32372.1476305527@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Vitaly Burovoy <vitaly(dot)burovoy(at)gmail(dot)com> writes:
> I'm sorry for the offtopic, but does anyone know a reason why a
> condition in mac.c
>> if ((a < 0) || (a > 255) || (b < 0) || (b > 255) ||
>> (c < 0) || (c > 255) || (d < 0) || (d > 255) ||
>> (e < 0) || (e > 255) || (f < 0) || (f > 255))
> can not be rewritten as:
>> if (((a | b | c | d | e | f) < 0) ||
>> ((a | b | c | d | e | f) > 255))
Well, it's ugly and it adds a bunch of assumptions about arithmetic
behavior that we don't particularly need to make. If this were some
amazingly hot hot-spot then maybe it would be worth making the code
unreadable to save a few nanoseconds, but I doubt that it is.
(Anyway, you've not shown that there actually is any benefit ...)
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2016-10-12 20:59:43 | Re: macaddr 64 bit (EUI-64) datatype support |
Previous Message | Alvaro Herrera | 2016-10-12 20:48:41 | Re: macaddr 64 bit (EUI-64) datatype support |