4.35. Storable

The module Storable provides most elementary support for marshalling and is part of the language-independent portion of the Foreign Function Interface (FFI) - see also Section 4.13. It provides a class Storable and instances of this class for all primitive types that can be stored in raw memory. The member functions of this class facilitate writing values of primitive types to raw memory (which may have been allocated with the above mentioned routines) and reading values from blocks of raw memory. The class, furthermore, includes support for computing the storage requirements and alignment restrictions of storable types.

Memory addresses are represented as values of type Ptr a, for some a which is an instance of class Storable. The type argument to Ptr helps provide some valuable type safety in FFI code (you can't mix pointers of different types without an explicit cast), while helping the Haskell type system figure out which marshalling method is needed for a given pointer.

All marshalling between Haskell and a foreign language ultimately boils down to translating Haskell data structures into the binary representation of a corresponding data structure of the foreign language and vice versa. To code this marshalling in Haskell, it is necessary to manipulate primtive data types stored in unstructured memory blocks. The class Storable facilitates this manipulation on all types for which it is instantiated, which are the standard basic types of Haskell, the fixed size IntXX (Section 4.18) and WordXX (Section 4.38) types, stable pointers (Section 4.34), all types from CTypes (Section 4.7) and CTypesISO (Section 4.8), as well as Ptrs (Section 4.29)).

class Storable a where
  sizeOf      :: a -> Int
  alignment   :: a -> Int

  peekElemOff :: Ptr a -> Int      -> IO a
  pokeElemOff :: Ptr a -> Int -> a -> IO ()

  peekByteOff :: Ptr a -> Int      -> IO a
  pokeByteOff :: Ptr a -> Int -> a -> IO ()

  peek        :: Ptr a             -> IO a
  poke        :: Ptr a        -> a -> IO ()
  
  destruct    :: Ptr a             -> IO ()

Minimal complete definition: sizeOf, alignment, one of peek, peekElemOff or peekByteOff, and one of poke, pokeElemOff and pokeByteOff. The behaviour of the member functions is as follows:

sizeOf :: a -> Int, alignment :: a -> Int

The function sizeOf computes the storage requirements (in bytes) of the argument, and alignment computes the alignment constraint of the argument. An alignment constraint x is fulfilled by any address divisible by x. Both functions do not evaluate their argument, but compute the result on the basis of the type of the argument alone.

peekElemOff :: Ptr a -> Int -> IO a

Read a value from a memory area regarded as an array of values of the same kind. The first argument specifies the start address of the array and the second the index into the array (the first element of the array has index 0). The following equality holds,

peekElemOff addr idx = IOExts.fixIO $ \result ->
  peek (addr `plusPtr` (idx * sizeOf result))

Note that this is only a specification, but not necessarily the concrete implementation of the function.

pokeElemOff :: Ptr a -> Int -> a -> IO ()

Write a value to a memory area regarded as an array of values of the same kind. The following equality holds,

pokeElemOff addr idx x = 
  poke (addr `plusPtr` (idx * sizeOf x)) x
peekByteOff :: Ptr a -> Int -> IO a

Read a value from a memory location given by a base address and offset. The following equality holds,

peekByteOff addr off = peek (addr `plusPtr` off)
pokeByteOff :: Ptr a -> Int -> a -> IO ()

Write a value to a memory location given by a base address and offset. The following equality holds,

pokeByteOff addr off x = poke (addr `plusPtr` off) x
peek :: Ptr a -> IO a

Read a value from the given memory location.

poke :: Ptr a -> a -> IO ()

Write the given value to the given memory location.

destruct :: Ptr a -> IO ()

Perform finalization (e.g. free an additional memory associated with the object) if poke does something which needs to be undone. A call to poke followed by destruct should leave resources in the same state as before. The default definition of destruct does nothing, as most types don't need any finalization.

Note that the peek and poke functions might require properly aligned addresses to function correctly. This is architecture dependent; thus, portable code should ensure that when peeking or poking values of some type a, the alignment constraint for a, as given by the function alignment is fulfilled.