[vm/ffi/NNBD] treatment of non-nullable and nullable C types

[dcharkes]

Currently, our representation of C types does not encode whether something can be null, and all types are represented as non-nullable.

Now that Dart will get NNBD, we might want to revisit that.

void MyCoolFunction(Foo& foo) {
  // ...
}

final f = dynamicLibrary.lookupFunction<Void Function(Pointer<Foo>),
                                        void Function(Pointer<Foo>)>("MyCoolFunction");
f(nullptr); // Passing null, without the Dart type system understanding it.

If we would like to represent the difference between references (non-nullable) and pointers (nullable), we could do so in the following way:

Pointer<Int8>  p1;  // non-nullable, a C++ Reference
Pointer<Int8>? p2;  // nullable,     a C++ Pointer

Then, we should also change the representation of the nullptr back to a Dart null instead of Pointer<Never>(address=0).

However, this also requires us to take real care that everywhere where we currently return Pointers with address 0, we return null instead:

• return values of FFI calls
• arguments of FFI callbacks
• loads from Pointer<Pointer<T>>.
• struct field loads.

Year old discussions (before NNBD): #35756.

cc @mkustermann @mraleph

[a-siva]

@dcharkes do we want this to be done for the beta release of the null-safety feature ?

[mkustermann]

@dcharkes do we want this to be done for the beta release of the null-safety feature ?

@a-siva I think this is rather a FFI design question how to represent a C pointer that is nullptr in Dart. Is not related/blocking to the NNBD work itself.

[mit-mit]

Removing from null safety tracking epic.