lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Fri, 25 Jul 2008 16:54:45 -0400 From: "H. Peter Anvin" <hpa@...or.com> To: Andrew Morton <akpm@...ux-foundation.org> CC: joerg.roedel@....com, linux-kernel@...r.kernel.org Subject: Re: [PATCH] introduce lower_32_bits() macro Andrew Morton wrote: >>> */ >>> #define upper_32_bits(n) ((u32)(((n) >> 16) >> 16)) >>> >>> +/** >>> + * lower_32_bits - return bits 0-31 of a number >>> + * @n: the number we're accessing >>> + */ >>> +#define lower_32_bits(n) ((n) & 0xffffffffULL) >>> + >> NAK. These are assymmetric with regards to type, which is the *last* >> thing we want. > > Yes, it will convert a 32-bit expression into a 64-bit one. > Sort of. upper_32_bits() takes a 32- or 64-bit expression, and delivers the upper 32 bits *as a 32-bit number*. An equivalent expression would be: ((u32)((u64)(n) >> 32)) ... which might actually produce better code, for all I know. Logically speaking, if we have a lower_32_bits() macro, it should also produce a 32-bit type as result. -hpa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists