关于DLL/C-Connect指针类型检查及参数传递问题的技术问询

咱们先拆解你的问题：先明确指针类型检查的默认状态，再聊聊能不能禁用，最后结合你之前遇到的UninterpretedBytes转void*的问题来分析细节。

1. 指针类型检查默认是启用的 #

你提到的CPointerType>>coerceForArgument:方法里的(anObject isKindOf: self defaultDatumClass)判断，就是类型检查的核心逻辑。对于void*这类通用指针，它默认只接受特定的指针包装类实例（比如对应平台的C指针对象），而UninterpretedBytes并不在允许范围内——这就是你之前无法直接传递的根源，类型检查直接拦住了操作。

2. 禁用指针类型检查是可行的，但要谨慎操作 #

如果你确实需要绕过这个检查，有几种实现方式：

• 修改核心方法（不推荐全局修改）：直接调整CPointerType>>coerceForArgument:的逻辑，比如把类型检查扩展为允许UninterpretedBytes，或者干脆跳过检查：

  CPointerType>>coerceForArgument: anObject
      ^ anObject isInteger 
          ifTrue: [anObject]
          ifFalse: [
              // 替换原有的类型检查逻辑，允许UninterpretedBytes
              (anObject isKindOf: self defaultDatumClass) or: [anObject isKindOf: UninterpretedBytes]
                  ifTrue: [anObject basicHandle]
                  ifFalse: [super coerceForArgument: anObject]]
  

• 创建子类重写方法：如果不想改动全局的CPointerType，可以创建它的子类，重写coerceForArgument:方法实现自定义类型检查逻辑，然后在你的DLL绑定中使用这个子类代替原指针类型。
• 临时元编程补丁：用Smalltalk的元编程能力，临时替换CPointerType的coerceForArgument:方法，完成特定调用后再恢复，这样影响范围更小。

3. 禁用检查的风险必须重视 #

跳过类型检查虽然能解决当前的传递问题，但会引入潜在危险：

• 内存访问错误：UninterpretedBytes的内存布局可能和C端void*预期的不一致；如果Smalltalk使用移动GC，对象内存可能被GC移动，导致C端拿到的指针失效，进而引发崩溃或数据损坏。
• 类型安全丢失：没有类型检查后，错误对象被传递给C函数的概率大幅提高，后续排查问题会变得非常困难。

其实如果你只是想传递UninterpretedBytes的内容给void*参数，还有更安全的替代方案：比如先将UninterpretedBytes的内存固定（避免GC移动），然后获取它的内存地址作为整数传递给C函数，C端再将整数转换为void*使用。

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