dart:ffi canonical representation of C null pointer in Dart

[dcharkes]

Should the canonical representation of a C null pointer be Pointer(address=0) or null?

Our current approach is null. This is very convenient when calling functions:

typedef NativeFunc = ffi.Pointer<ffi.Int64> Function(ffi.Pointer<ffi.Int64>);
NativeFunc f = somePointer.asFunction();
ffi.Pointer<ffi.Int64> result = f(null); // will be passed as nullptr
Expect.isNull(result); // result is Dart null if c returns nullptr

However, this also means that our Pointer.fromAddress(0) factory should return null.
Which would mean Pointer.fromAddress(0).getAddress() does not return 0 but throws an exception.

On the other hand, if Pointer(address=0) would be the canonical representation then the above snippet would be the following more verbose code instead:

ffi.Pointer<ffi.Int64> result = f(Pointer.fromAddress(0));
Expect.isEqual(0, result.getAddress());

Another aspect is that the Dart null object does not carry a runtime type.
A pointer with address 0 does carry a runtime type argument:

Pointer p = Pointer.fromAddress<Int64>(0)

Would this runtime type argument for address 0 be useful in some scenario?

[lrhn]

My recommendation: Don't use null.

Do introduce a constant, say NULL of type ffi.Pointer<ffi.Void> (if a void type exists, otherwise use a byte pointer) and let people use that.
(It's not idiomatic Dart naming to use SCREAMING CAPS, but it is C style, and this is a C NULL pointer, so I'd accept it - the domain overrules the general style).

Maybe accept null on inputs, and convert it to NULL (at least until we get non-nullable types), but never return null.

Counter-argument: If you ever want to have functions that don't accept null pointers, and we have non-nullable types, and the null-pointer is null, then things are easy. Otherwise you need to do: if (input == null || input.isNull) throw ....

Naming Nitpick: Do not use getAddress(), make it a getter :)

[dcharkes]

Great suggestion!

Any suggestion for what we should do with our struct sugar syntax abstraction?

@ffi.struct
class Coordinate extends ffi.Pointer<ffi.Void> {
  @ffi.Double()
  double x;

  @ffi.Double()
  double y;

  @ffi.Pointer()
  Coordinate next;
}

Should getters which point to other structs return NULL or null?
null would enable more natural interaction with things like nullable calls etc.

Coordinate c;
c.next?.someMethod();

I guess the design question is: should interaction with structs feel more like Dart code or more like C?

[lrhn]

For the Coordinate example, I'd treat Coordinate as a Dart type (nullable using null) and not as a pointer (and not make it extend Pointer).

If it actually extends Pointer, would NULL actually be a valid Coordinate value? If so, use that. Don't have two different null values.

[dcharkes]

After deciding on how to represent null we could also consider the following.

On Linux, malloc(0) returns NULL. Maybe we should do the same?

note: currently allocate(count: 0) throws an Exception

[dcharkes]

This needs to be done together with #37229 assigning to @sjindel-google.

[sjindel-google]

There is no NULL in C -- but many standard library define it as 0. We should use nullptr instead since it's actually specified in C++.