From: | Vitaly Burovoy <vitaly(dot)burovoy(at)gmail(dot)com> |
---|---|
To: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
Cc: | 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>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "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:44:35 |
Message-ID: | CAKOSWNk87u3-qZX2yixts7wZ3ao_kwv+XB8+ePB5txFg82r3+A@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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))
It seems more compact and a compiler can optimize it to keep a result
of a binary OR for the comparison with 255...
--
Best regards,
Vitaly Burovoy
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2016-10-12 20:45:54 | Re: macaddr 64 bit (EUI-64) datatype support |
Previous Message | Tom Lane | 2016-10-12 20:33:38 | Re: munmap() failure due to sloppy handling of hugepage size |