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. 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 |
Hi Ben,
On Tue, Sep 27, 2016 at 8:40 AM, Ben Coman <[hidden email]> wrote: First, my C is a bit rusty so a question about semantics... 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 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 |
Free forum by Nabble | Edit this page |