[ffi] Add support for abi-specific integer sizes

[mkustermann]

We should consider exposing our Abi enum and allow users to have ABI-specific types. This would avoid us having to continuously increase the set of types we support in the core dart:ffi library. It would also allow a ffi bindings generator to produce ABI agnostic bindings.

We would support the primitive integer, double and pointer types in dart:ffi anything else can be user defined.

One option would be using non-function type aliases (see dart-lang/language#65), which could look like this:

typedef WChar = AbiSpecificType<Int8, Int16, ...>;

class MyStruct extends Struct {
  @WChar()
  int char;
}

void foo(Pointer<WChar> chars);

where dart:ffi would have

class AbiSpecificType<ABI1, ABI2, ...> {}

When the VM compiles code it will know which ABI it runs on and can use the corresponding type from the instantiated AbiSpecificType.

One downside here is that we would have a hard time adding more ABIs in the future (though in reality we rarely add new architectures / operating systems / compilers)

/cc @dcharkes wdyt?

[mkustermann]

@dcharkes There is actually a way to make this more extensible to future ABIs:

abstract class WChar implements LinuxArmHardFp<Int8>,
                                LinuxArmSoftFp<Int16>,
                                WindowsX64FastCallAbi<Int32>,
                                ... {}

Adding a new Abi would then just add a new class to dart:ffi which is not breaking compatibility. When running the program on an Abi that WChar was not implemented the VM could throw an exception (or a compile-time error).

[dcharkes]

I like it! We might still need to make it extend AbiSpecificInteger or make all those individual ABIs do that, in order to be able to have Pointer<WChar> and be able to store/load from it through extension methods.

This also means we would not have to wait on generalized typedefs (or result to subtyping) to be able to reuse the type in multiple places.

[mkustermann]

There's also a design choice: In C code two typedefs are compatible and assignable to each other. If we do the generalized typedef approach we will have the same behavior, if we go with a separate class then one needs to explicitly cast in Dart (but not in C).

[dcharkes]

True, if the one package decides to call wchar_t WChar and another package decides on WCharT they wont match.

Maybe we should preempt that by adding some of those to package:ffi, and have people make PRs for adding more common types.

[dcharkes]

We also need something for structs. We cannot merge the two concepts in one Dart type, because the int loads/stores only work for ABI-sized integers, and the struct field loads/stores only work for structs.

[mkustermann]

Not sure how common it is in C to have a typedef to be integer typed on one platform and non-integer on another. Maybe that is not worth adding support for.

[artob]

abstract class WChar implements LinuxArmHardFp<Int8>,
                                LinuxArmSoftFp<Int16>,
                                WindowsX64FastCallAbi<Int32>,
                                ... {}

Adding a new Abi would then just add a new class to dart:ffi which is not breaking compatibility. When running the program on an Abi that WChar was not implemented the VM could throw an exception (or a compile-time error).

That looks pretty great.

True, if the one package decides to call wchar_t WChar and another package decides on WCharT they wont match.

Maybe we should preempt that by adding some of those to package:ffi, and have people make PRs for adding more common types.

Yes, these really should be provided by the Dart project in one form or another. You'd want to avoid the situation with e.g. Java JNA when there's a bunch of different definitions of the same common types (e.g., ssize_t), and nobody knows which type they ought to be using.

[dcharkes]

@mkustermann The typedef solution does not work for struct fields (annotation constructor calls cannot have type arguments), so that solution also requires subtyping.

I've prototyped three API variants in https://gist.github.com/dcharkes/8d41b7def9bf82c74bf0b7f8a1d66a6c.

@lrhn @eernstg Any feedback from a language design point of view on the possible APIs?