Support for bitfields in structs

[mannprerak2]

Bitfields are not directly supported in dart:ffi but it may be possible to generate code to work with it. See dart-lang/sdk#38954.

[dcharkes]

This is a great feature to add to package:ffigen indeed.

[mannprerak2]

It may not be possible to generate bitfields for structs, because of padding issues.

Consider a struct S -

typedef struct
{
    int *a;                             // Can be 4 or 8 bytes
    long long b:35;             // Takes 5 bytes
    char c;                           // Takes 1 byte
} A;

The memory layout for this should be similar to this, The offset of char c is 13 on both 64 and 32-bit compilers, you can test it out here - (https://godbolt.org/z/4e3ET8) -

This 64-bit layout can be confirmed by clang's output

$ clang -Xclang -fdump-record-layouts test.c

*** Dumping AST Record Layout
         0 | A
         0 |   int * a
    8:0-34 |   long long b
        13 |   char c
           | [sizeof=16, align=8]

For generating 32-bit layout on my 64-bit machine, I simply replaced int *a with int a (I suppose it doesn't make a difference)

clang -Xclang -fdump-record-layouts test.c     

*** Dumping AST Record Layout
         0 | A
         0 |   int a
    8:0-34 |   long long b
        13 |   char c
           | [sizeof=16, align=8]

Here's why we cannot generate platform-agnostic bindings for this struct with bitfield -

for representing long long b:35

• If we use an Int64 this will also end up including the char c inside it.
• If we use a combination of ints less (in size) than Int64 It will be placed immediately after int *a, and because int *a can end anywhere depending on architecture, this won't be platform-agnostic.

Also, it's possible to pack the structure tightly (using __attribute__((packed)), in which case again, any generated bindings will be useless. See related issue for this -> dart-lang/sdk#43247 dart-lang/sdk#38158

Considering all that, it seems more viable to have bitfields in dart:ffi and let dart VM handle the padding.
We should reopen -> dart-lang/sdk#38954 in that case.

[dcharkes]

Good find. A good middle ground solution would be to add some alignment directives to dart:ffi:

class A extends Struct {
  Pointer<Int> a;

  @AlignedTo(8)
  Int8()
  int _b0;
  Int8()
  int _b1;
  // ...

  Int8()
  int c;
}

I filed dart-lang/sdk#43257 to support that.

[mannprerak2]

I am not sure if we will be able to tell which alignment to use.
For example this struct,

typedef struct
{
    char a;
    long long b:30;
} A;

has the following layout

*** Dumping AST Record Layout
         0 | A
         0 |   char a
    1:0-29 |   long long b
           | [sizeof=8, align=8]

I would have expected long long b:30 to start from the 4-byte boundary, but the compiler is basically trying to use minimum space while making sure that those fields can be accessed with minimum read cycles.

Here we must use @AlignedTo(1) but

• If we replace char a with int *a we will have to use @AlignedTo(4).
• If we had 5 chars before long long b:30 we would again need to use AlignedTo(4)

[bvoq]

I would suggest omitting the bitfield information when generating the code.
If I understood the documentation correctly this would still be compliant C code (specifically, it must not be greater than size of the type with the bit information omitted).
https://stackoverflow.com/questions/32677235/bit-fields-memory-management-in-c

That's how I've called my C code with bitfield information and it worked well.

unsigned int sid      : 8;
unsigned int mlength  : 31;

would be interpreted as

unsigned int sid;
unsigned int mlength;