Hi Ben, On Tue, Sep 27, 2016 at 8:40 AM, Ben Coman <btc@openinworld.com> wrote:

First, my C is a bit rusty so a question about semantics...

int * a; typedef int * MyInt; MyInt b;

So obviously the type of 'a' is a pointer, but is the type of 'b' a pointer? My intuition is that its not, since the pointer is wrapped inside the type.

Yes it is. MyInt (a bad name) is a type that is a pointer to an int. So something of type MyInt is of type pointer to int.

Now in my UFFI tutorial http://blog.openinworld.com/2016/09/pharo-libclang-ffi- part-4-ast-walking-with-visitors-callbacks/ I have a callback that I've modified here adding the #inspect...

acceptCallbackFn := FFICallback signature: #( CXChildVisitResult ( CXCursor cursor, CXCursor parent, CXClientData client_data)) block: [ :cursor :parent :clientData | client_data inspect. visitResult add: cursor kind item. aCXChildVisitResult value "@1" ].

This can be invoked by running #testVisitChildrenCallbackBreak and an inspector opens on an ExternalAddress instead of the expected CXClientData.

FFIExternalObject subclass: #CXClientData instanceVariableNames: '' classVariableNames: '' package: 'Libclang'

where the FFIExternalObject says... "A typical usage of me is to create a subclass, and then use that subclass name directly in function signatures ... By putting FFIExternalObject subclass ... as a return type into the function signature, we are telling the code generator to ***automatically*** convert the return value into an instance of a given class and initialize its handle to the value returned by the function."

This decision to return ExternalAddress instead of CXClientData occurs here... FFIExternalObjectType(FFIExternalType)>>handle: aHandle at: index self isPointer ifTrue: [ ^ aHandle pointerAt: index ]. ^ self basicHandle: aHandle at: index

since... FFIExternalType>>isPointer ^ self pointerArity > 0

and... FFIExternalObjectType(FFIExternalReferenceType)>>naturalPointerArity ^ 1

So this naturalPointerArity=1 represents the situation presented with the C code at the top. So should #isPointer consider only the absolute pointerArity, or should is be...

FFIExternalType>>isPointer ^ self pointerArity > self class naturalPointerArity

Indeed, if I do that, plus these two additions copied from FFIExternalStructure...

FFIExternalReferenceType>>basicHandle: aHandle at: index ^ self objectClass fromHandle: aHandle.

FFIExternalReference>>fromHandle: aHandle ^self basicNew setHandle: aHandle

Now running #testVisitChildrenCallbackBreak opens an inspector opens on a CXClientData as expected. And all UFFI tests continue to run fine.

One thing I found strange though was... FFIExternalStructureType>>naturalPointerArity ^ 1

I would have thought a struct's natural pointer arity was 0 ?

wdyt? cheers -ben

This makes my brain hurt. A pointer is a pointer, whether it points to a pointer or a datum. Hence I find the "self pointerArity > self class naturalPointerArity" approach confusing. _,,,^..^,,,_ best, Eliot