Strongly Specify Alignment for FFI Allocation

Thomas DuBuisson thomas.dubuisson at
Thu Sep 24 23:12:41 EDT 2009


The verbiage here is borrowed from other parts of the report under the
belief it helps readability.

Option 1: A global note applying to all functions that allocate
memory.  Proposed wording for section 5.0:

"All successful results of allocation routines will be sufficiently
aligned for any of the basic foreign types (see Section 3.2) to fit
into a memory block of the allocated size.  Array allocation routines
will result in the same alignment as the member elements."

I believe this to be quite clear but if people here are unsatisfied
then a list of example functions could be added at the risk of being
tacky.  Or we could avoid specifying functions by mentioning
categories of functions at the risk of muddying the waters:

"This alignment guarantee applies equally to computation-bound
allocations, ForeignPtr references, and Ptr references."

Option 2: Individual notes for all allocation routines

Add to both mallocForeignPtr and mallocForeignPtrBytes:
"The same alignment constraint as for mallocBytes holds."

Add to both mallocForeginPtrArray and mallocForeignPtrArray0:
"The resulting pointer will be suitably aligned to hold values of type b."

Many other functions aren't so deficient as to require extra words -
they contain references to functions that already have alignment
comments, "These functions behave like x, y, z".  Still, this hazy
area is why I prefer option 1.

If people actually prefer option 2 then I'll do a more through vetting
of the function descriptions and likely come up with a larger list of


On Thu, Sep 24, 2009 at 7:08 PM, Manuel M T Chakravarty
<chak at> wrote:
> Thomas DuBuisson:
>> Aside from section 5.7 (storable) and comments on 'alignPtr', the only
>> mention of alignment in the FFI addendum is on
>> mallocBytes/allocaBytes:
>> "The block of memory is sufficiently aligned for any of the basic
>> foreign types (see Section 3.2) that fits into a memory block of the
>> allocated size"
>> It would be beneficial if this wording was applied to all allocation
>> routines - such as mallocForeignPtrBytes, mallocForeignPtrArray, etc.
>> For the curious, this proposal was born from the real-world issue of
>> pulling Word32's from a ByteString in an efficient but portable manner
>> (binary is portable but inefficient, a straight forward
>> unsafePerformIO/peek is efficient but need alignment).
> I agree that we should be more precise here.
>> If no glaring issue comes up then I'll formalize / make a ticket,
> Can you please summarise the exact additions that you would like to see as a
> follow-up email?  I will collect all changes that we want to make to the
> existing FFI Addendum before it goes into the 2009 issue of Haskell'.
> Cheers,
> Manuel

More information about the Haskell-prime mailing list