taylanbayi...@gmail.com (Taylan Ulrich "Bayırlı/Kammer") writes:
> That's all there is to it, and you could populate those bytes directly,
> one by one:
>
> the_struct_t my_struct = { a, b, c, d, e, f }
>
Whoops, C isn't as dumb as I had in memory. You'll need to memcpy it
into a char[] to be able to hack on the bytes that freely. Anyway.
So I've been made aware that if I want my library to work with C data
structures, I'll probably want to add alignment support. :-)
I did that now, though I don't know if I did it right because I couldn't
find precise information on what an FFI system should support
wrt. data structure alignment. I read a little on Wikipedia and peeked
into the documentation of Haskell's FFI and CL's CFFI.
The struct constructor takes an `align?' argument now, which if true
will enable default alignment for struct fields.
E.g.
struct { uint8_t; uint16_t; uint64_t; }
becomes:
1: 1 byte uint8
2: 1 byte padding so uint16 is 2-byte aligned
3-4: 2 bytes uint16
5-8: 4 bytes padding so uint64 is 8-byte aligned
9-16: 8 bytes uint64
16 bytes in total. The struct's own alignment is 8, equal to the
alignment of its element with the highest alignment.
Vectors' alignment is equal to that of their element-type's alignment.
Unions' is equal to their highest member.
I see C compilers support stuff like "pack(2)" to force 2-byte alignment
for >2 byte sized fields. I might add support for that too; I don't
know if C libraries typically use that for their ABI?
---
Next up I'll see if I can implement some example programs using the
library. Something parsing a binary file format, something using the
FFI to work with some C data structures, etc.
On the meanwhile, testers and feedback welcome.
Taylan
