Doubly agreed -- similar patterns appear elsewhere to avoid off-by-one errors and bitmasking is fairly intuitive to anyone regularly working at that level. I was surprised at the author not recognizing this idiom, but you have to learn it sometime!
I was further stunned by the seeming naivety of the author's align_2() implementation, but then it does get the job done, eventually. My naive approach would've been roughly align_3(), but using integer math and modulus.
On the other hand, younger team members were recently stunned by code I did for translation of a binary protocol into more easily handled pieces using what I think of as typical idioms, so this article might get sent around Monday morning.
Hi, author here. My align_2 implementation is indeed very naive. Part of that was to show just how much overhead a naive implementation could add, in this case 3 orders of magnitude. I'm also new to systems programming. This article should serve as a reminder to experienced hackers that idioms are often only obvious _after_ they've been explained. My last 4 years were spent working on a distributed database; I could bring up "obvious" idioms from that world that might perplex a kernel hacker.
But you are right, this is indeed a very obvious line of code once you understand it. Thank you for your comments.
The key being "once you understand it." I look forward to sending this around to make sure folks "get it" -- that which I grasp intuitively is magic for them[1], and kernel hacking is rarely the deep topic people imagine it to be. I doubt I have the right perspective to explain this as clearly, and if I could, I lack the time to do so as deeply.
Looking at code from the 80's, it is quite common to come across code that is extremely explicit about types, and that exploits known type sizes of the target platform, overflow behaviour etc.
E.g. modern C code tends to use "int" or "long" all over the place without considering if "short" or "char" is likely to be sufficient.
Similarly, you'll find bit fiddling wherever it is possible, including a tendency to use bit shift instead of multiply/divide even for constant factors where one might thing the compilers would optimize it to shifts (many early compilers didn't).
So it's not necessarily just an idiom of systems programming, as an idiom amongst "old school" C programmers in general. The extent to which it has carried through to more modern code, varies, though. I suspect systems programming has an overall higher ratio of "old school" C developers than application code does.
> E.g. modern C code tends to use "int" or "long" all over the place without considering if "short" or "char" is likely to be sufficient
"Sufficient" is bit odd choice of word here. Word-sized types should be used unless there is a good reason not to. See nkurzs comment for a great example for this:
> The first 'movl' wipes out any bits greater than 32 if they are there. This is because x was defined as an int, and not a long.
Or for consistency with the rest of the code. It is one way, if not the fastest way to do alingment. Every systems programer knows that pattern, it is easily recognizable. You find it plentiful in kernels and low-level system libraries.
I was further stunned by the seeming naivety of the author's align_2() implementation, but then it does get the job done, eventually. My naive approach would've been roughly align_3(), but using integer math and modulus.
On the other hand, younger team members were recently stunned by code I did for translation of a binary protocol into more easily handled pieces using what I think of as typical idioms, so this article might get sent around Monday morning.