#include <stddef.h>
#let alignment t = "%lu", (unsigned long)offsetof(struct {char x__; t (y__); }, y__)

instance Storable Foo where
    sizeOf    _ = #size struct foo
    alignment _ = #alignment struct foo
    {- ... -}

Anyway after further exploration down the rabbit hole that is GHC’s source code I am pretty sure that the alignment field in the type class Storable is not actually used in the implementation of allocating memory. It seems to be purposed as information that can be queried by the programmer and little more. So having an alignment of 1 does no more than mislead a programmer… not the low level allocation routines.

For what it is worth, here is an interesting approach to computing alignment using C++ templates.

Alignment becomes of particular concern when dealing with SSE on x86 and AltiVec on PowerPC. As these instructions work on 128bit/16byte data chunks, they must be 16 byte aligned. I’m assuming that GHC doesn’t support these instructions, however if you wanted to add it, you would have to make sure that the allocation routines respected these constraints… and thus the flip-side of my above observation is that defining alignment to be 16 wouldn’t cut it.

Thanks for that excellent comment. My original code still has some question marks after the alignment since I wasn’t sure of it. I’ll modify the post to correct for my new-found knowledge.

One thing I’m still wondering though, is it always that easy, just pick the size of the largest (built-in) data type within the struct, or will the CPU’s address size or word size ever play a role? I guess what I’m really wondering is if I have to take special care to write code to run on both 32-bit and 64-bit platforms?

So your implementation of sizeOf, peek and poke are fine, however defining alignment to be 1 is not! An incorrect alignment will work for x86 however a program will suffer a significant performance penalty and in other architectures it will raise an exception in the processor!

Wikipedia has an entry on struct alignment which references a short definition and example of alignment on MSDN, an article on IBM developerworks discussing the performance issues with alignment as well as a further article about alignment. In addition to its article, MSDN has a collection of alignment examples. As an aside here is an article discussing the implications of structure padding.

To summarize: Your particular struct should have an alignment of 4 not 1. An int (32bit) has a size of 4 bytes and an alignment of 4 (You can verify this with ghci). Therefore an int must be placed at a memory location which is divisible by 4. When an int is within a structure, the structure is padded to ensure that the int starts at a 4 byte boundary relative to the start of the structure. However if the structure were to be misaligned in memory the int would not aligned in the global sense. Therefore the structure should also have an alignment of 4. To correct your specific example:

alignment _ = alignment (undefined::CInt)

In general the struct should have the same alignment as the largest data type within the struct. So for example a double is 8 byte aligned on Windows and 4 byte aligned on Linux and OS X, so a struct with a double or a 64 bit integer is likely to be the largest data field and thus the struct will have a matching alignment. While all of the links above discuss structure padding rather than structure alignment explicitly, I believe my rule is correct and that the same logic holds for C unions.

Finally, GCC has an extension which allows one to programmatically query the alignment for data types. You can use this to experiment with more complex structs such as the examples that MSDN provide and verify my claims.