Skip to content

dart:ffi Void size one byte or unknown #35879

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
dcharkes opened this issue Feb 7, 2019 · 5 comments
Closed

dart:ffi Void size one byte or unknown #35879

dcharkes opened this issue Feb 7, 2019 · 5 comments
Labels
area-core-library SDK core library issues (core, async, ...); use area-vm or area-web for platform specific libraries. library-ffi type-design

Comments

@dcharkes
Copy link
Contributor

dcharkes commented Feb 7, 2019

Should Void have a size of 1 byte, or an unknown size.

Defining a size would allow the following

Pointer<Void> p = allocate(count: 20);
Pointer<Void> p2 = p.elementAt(10);
sizeOf<Void>(); // returns 1

Keeping Void opaque, not knowing its size would disallow allocate and sizeOf:

Pointer<Void> p = allocate<Int8>(count: 20).cast();
Pointer<Void> p2 = p.offsetBy(10);
sizeOf<Void>(); // throws exception

cc @sjindel-google

@dcharkes dcharkes added the area-core-library SDK core library issues (core, async, ...); use area-vm or area-web for platform specific libraries. label Feb 7, 2019
@sjindel-google
Copy link
Contributor

We can allow pointer arithmetic on a Pointer<Void> without necessarily allowing allocate and sizeOf.

@dcharkes
Copy link
Contributor Author

dcharkes commented Feb 7, 2019

We already allow offsetBy on Pointer<Void>.

@sjindel-google
Copy link
Contributor

sjindel-google commented Feb 7, 2019

Right, I'm just saying that we could allow elementAt as well, for consistency with C.

@dcharkes
Copy link
Contributor Author

It is not C or C++ semantics, it's a non standard extension in GNU C.

6.24 Arithmetic on void- and Function-Pointers

In GNU C, addition and subtraction operations are supported on pointers to void and on pointers to functions. This is done by treating the size of a void or of a function as 1.

A consequence of this is that sizeof is also allowed on void and on function types, and returns 1.

The option -Wpointer-arith requests a warning if these extensions are used.

https://gcc.gnu.org/onlinedocs/gcc/Pointer-Arith.html

I prefer keeping things consistent with regard to being sized or not.

Sized:

  • Int8, ..., Double, Float
  • Pointer
  • subtypes of Struct

Not sized:

  • NativeType
  • NativeInt
  • NativeDouble
  • NativeFunction
  • Void
  • Struct

Everything that is sized can be used in allocate, sizeOf, elementAt, load, and store.

Note that in our implementation before #37254 we require load and store to be statically typed as a sized thing, while we fail sizeOf, elementAt, and allocate dynamically. We do the latter so that you can write generic code. After landing #37254 all of these will be dynamic.

If we use extension methods we could even try using NativeSized in the hierarchy, and only define these 5 operations on those. This would almost work: you could still try to call them on Struct and NativeSized even though these are not sized themselves.

@sjindel-google
Copy link
Contributor

👍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area-core-library SDK core library issues (core, async, ...); use area-vm or area-web for platform specific libraries. library-ffi type-design
Projects
None yet
Development

No branches or pull requests

2 participants