On Tue, 20 Mar 2012 12:32:14 +0100 Michal Nazarewicz <mina86@xxxxxxxxxx> wrote: > >+#define ALIGN_OF_LAST_BIT(x) ((((x)^((x) - 1))>>1) + 1) > > Wouldn't ALIGNMENT() be less confusing? After all, that's what this > macro is calculating, right? Alignment of given address. Why not just LAST_BIT(x)? It's not particularly specific to pointer alignment, even though that's the context in which it apparently came up. So far as I can tell, this isn't even meaningfully defined on pointer types as such; you'd have to convert. So the implications for alignment seem a convenient side-effect, really. It might be instructive to see some example proposed uses; the question of why I'd care what alignment something had, rather than whether it was aligned for a given type, is one that will doubtless keep me awake nights. I guess this feels like it answers a question that is usually the wrong question. Imagine if you will a couple-page block of memory, full of unsigned shorts. Iterate through the array, calculating ALIGN_OF_LAST_BIT(&a[i]). Do we really *care* that it's PAGE_SIZE for some i, and 2 (I assume) for other i, and PAGE_SIZE*2 for either i==0 or i==PAGE_SIZE? (Apologies if this is a silly question; maybe this is such a commonly-needed feature that it's obvious.) -s -- Listen, get this. Nobody with a good compiler needs to be justified. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/ Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>