Re: macaddr 64 bit (EUI-64) datatype support
От | Vitaly Burovoy |
---|---|
Тема | Re: macaddr 64 bit (EUI-64) datatype support |
Дата | |
Msg-id | CAKOSWNkEYtB0kbd-9mvpZzBDOXR=MW2eZWJO8nEBH6Rz8WE-Wg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: macaddr 64 bit (EUI-64) datatype support (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | 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
В списке pgsql-hackers по дате отправления: