为何无法通过DLL/C-Connect将UninterpretedBytes传递给void*？

我之前在Smalltalk里调用外部C库时也踩过这个坑，直接传UninterpretedBytes到C方法时，默认的类型转换逻辑（也就是CPointerType>>coerceForArgument:anObject）没法正确识别它的内存结构，所以才会报错。不想用gcCopyToHeap拷贝内存的话，有几个直接操作Smalltalk内存的方案，而且能保留1基地址的特性：

方案1：直接获取UninterpretedBytes的原始内存指针 #

UninterpretedBytes的底层存储是连续的内存块，而且Smalltalk是1基索引，所以第一个元素的地址就是我们要传给C库的void*起始地址。你可以用addressOf:方法直接拿到这个地址，不用拷贝：

MyApplication>>test
    buffer := UninterpretedBytes new: 4.
    "拿到指向buffer第一个元素的原始指针，直接对应Smalltalk内存区域"
    bufPtr := buffer addressOf: buffer basicAt: 1.
    ^ MyLibrary new foo: bufPtr len: buffer size.

这个方法直接跳过了默认的类型转换，把Smalltalk内存里的原始地址传给C库，完全符合你的需求。

方案2：自定义外部调用的参数转换 #

如果你不想在调用处写额外的指针获取逻辑，可以修改MyLibrary>>foo:len:的实现，自定义参数的 coercion 逻辑，绕开默认的CPointerType处理：

MyLibrary>>foo: buf len: len 
    <C: int foo(void *buf,unsigned int len)>
    "手动指定参数转换，直接传递buf的内容起始地址"
    ^ self cCall: #(int foo (void *buf, unsigned int len))
        args: { buf addressOf: buf basicAt: 1. len }

这样以后调用foo:len:的时候，直接传UninterpretedBytes对象就行，内部会自动处理指针转换。

重要注意事项 #

• GC安全：同步调用外部库的话，只要调用过程中buffer对象不会被GC回收或移动就没问题；如果是异步调用（比如C库会在后台使用这个指针），一定要把buffer固定在内存里，比如用Pharo/Squeak里的buffer pin方法，防止GC移动内存导致指针失效。
• VM兼容性：上面的方法在主流Smalltalk VM（Pharo、Squeak）里都能正常工作，但不同VM的对象内存布局可能有细微差异，如果是其他小众VM，可能需要调整获取地址的方式。

内容的提问来源于stack exchange，提问作者aka.nice