Stack allocation and alignment

[slburson]

Just started using CFFI, and I'm curious about something. There is machinery to compute the alignment of any type, but with-foreign-pointer doesn't accept an alignment; on SBCL, it calls sb-alien:with-alien requesting a byte (octet) array, which presumably has alignment 1. with-foreign-object knows the desired type and in principle could guarantee the required alignment, but there's no code to do this.

Now, this seems like the kind of thing that would have been fixed years ago if it actually caused SIGBUS or whatever on some CPUs. (I gather that x86-64 handles misalignment without complaint, albeit at some performance cost.) But I'm still curious exactly how we get away with it. Are stack allocations in all CL implementations guaranteed to produce a pointer with the largest alignment the hardware could require?

[sionescu]

SBCL's WITH-ALIEN calls malloc underneath, which is guaranteed to return DWORD alignment. For larger alignments, you can use posix_memalign() or static-vectors.

…

On July 5, 2026 00:52:38 "Scott L. Burson" ***@***.***> wrote: Just started using CFFI, and I'm curious about something. There is machinery to compute the alignment of any type, but with-foreign-pointer doesn't accept an alignment; on SBCL, it calls with-alien requesting a byte (octet) array, which presumably has alignment 1. with-foreign-object knows the desired type and in principle could guarantee the required alignment, but there's no code to do this. Now, this seems like the kind of thing that would have been fixed years ago if it actually caused SIGBUS or whatever on some CPUs. (I gather that x86-64 handles misalignment without complaint, albeit at some performance cost.) But I'm still curious exactly how we get away with it. Are stack allocations in all CL implementations guaranteed to produce a pointer with the largest alignment the hardware could require? — Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today! You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

-- Stelian Ionescu

[luismbo]

It might stack allocate too. Could be more of a problem in that case, maybe?

The alignment stuff is definitely meant for structs. Alignment within the heap/stack was never a consideration.

[slburson]

I see: people just haven't generally been stack-allocating structs. And I should assume that only single-word alignment is guaranteed in that case.

The library I am calling via CFFI contains this:

template <typename T>
struct alignas(sizeof(T) * 2) complex {
  T real_ = T(0);
  T imag_ = T(0);
  // ...
};

which means that complex<double> requires 16-byte alignment. I don't know whether this is a hard requirement, perhaps because SIMD instructions are being used, or just a minor performance preference to make sure an instance is never split across a cache line boundary. But I think I should assume it's a hard requirement.

This suggests two desirable features:

• CFFI currently assumes that the alignment of a struct can be computed as the maximum alignment of its fields. Since this assumption does not always hold, there should be ways to override the alignment, ideally either by annotating the type or by supplying an alignment directly to with-foreign-object or with-foreign-pointer.
• Since sb-alien:with-alien does not accept an alignment, probably with-foreign-pointer should do the alignment itself, by requesting a - 1 additional bytes and adjusting the pointer.

For the moment, I can work around the issue by writing my own version of with-foreign-object that handles the alignment.