Hi all!

For some days now, I am thinking about "pointer-to-pointer" types. I suppose that the more general topic is the interpretation of multi-dimensional arrays.

On the one hand, this is an in-image issue to correctly read ExternalData and to generate appropriate accessors for struct fields.

On the other hand, this may affect FFI call's arg coercing and return-type packaging.

So, after playing around with an implementation of pointer-to-pointer types via ExternalType's #referencedType (i.e. making it a chain of three: ... -> void -> void* -> void** -> void ...), I figured that we might need to store the array dimensions in the compiledSpec.

Here are some unused bits for that:

FFIFlagPointerArrayMask := 16rF00000. "up to 16-dimensional arrays"
FFIFlagPointerArrayShift := 20.

Here are some questions for you on this topic:

- Should we reserve all 4 bits? 16-dimensional arrays sound like overkill ... 2 bits could be enough, having rarely the lower one set for char** ...
- In the image, would you store all possible versions through refrencedType in a linked cycle? Or would you lazily create them ... on the fly? As requested from struct fields and FFI call specs via ExternalType class >> #typeNamed: ?
- In the FFI plugin, do you see value in coercing an array of, for example, IntegerArrays for an FFI call? (int**)
- In the FFI plugin, do you see value in automatically packaging returned objects if those dimensions would be zero-terminated?

Best,
Marcel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200614/4371ea63/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 15519 bytes
Desc: not available
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200614/4371ea63/attachment.png>