On 10/12/16, Tom Lane <t...@sss.pgh.pa.us> wrote: > Vitaly Burovoy <vitaly.buro...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
