Re: macaddr 64 bit (EUI-64) datatype support
Vitaly Burovoy <vitaly.burovoy@gmail.com>
From: Vitaly Burovoy <vitaly.burovoy@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Alvaro Herrera <alvherre@2ndquadrant.com>,
Julien Rouhaud <julien.rouhaud@dalibo.com>, Craig Ringer <craig@2ndquadrant.com>,
Haribabu Kommi <kommi.haribabu@gmail.com>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2016-10-12T21:11:35Z
Lists: pgsql-hackers
On 10/12/16, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Vitaly Burovoy <vitaly.burovoy@gmail.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. It explains the reason, thank you. I'm just not familiar with other architectures where it is not the same as in X86/X86-64. > 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 ...) I don't think it has a speed benefit, especially comparing with the sscanf call. But personally for me the second variant does not seem ugly, just "no one bit in all variables is out of a byte" (looks better with comparison with "0xff" as sscanf operates with "%2x"). Sorry for my bad taste and for a noise. -- Best regards, Vitaly Burovoy
Commits
-
Add support for EUI-64 MAC addresses as macaddr8
- c7a9fa399d55 10.0 landed
-
perltidy pg_dump TAP tests
- 6af8b89adba1 10.0 cited