通过C void*在Fortran中传递任意数据的安全性与实现问询

问题背景 #

我有一个C库，提供以下接口存储/获取指向任意C数据的void*指针：

void set_pointer(void* user_ptr);
void* get_pointer();

需要构建Fortran接口，让这个void*可以指向任意C互操作的Fortran派生类型。已实现的基础Fortran接口（基于iso_c_binding）如下：

interface
    subroutine c_set_pointer(usr_ptr) bind(C, name="set_pointer")
        use, intrinsic :: iso_c_binding
        implicit none
        type(c_ptr), value, intent(in) :: usr_ptr
    end subroutine c_set_pointer
end interface

interface
    function c_get_pointer() result(usr_ptr) bind(C, name="get_pointer")
        use, intrinsic :: iso_c_binding
        implicit none
        type(c_ptr) :: usr_ptr
    end function c_get_pointer
end interface

示例C互操作派生类型：

type, bind(C) :: UserData
    integer :: i
    real :: f
end type UserData

当前实现 #

设置指针（依赖Fortran 2018假定类型）

subroutine set_pointer(data)
    use, intrinsic :: iso_c_binding
    implicit none
    type(*), target, intent(in) :: data

    call c_set_pointer(c_loc(data))
end subroutine set_pointer

注：目标是实现纯Fortran 2003版本，而假定类型是Fortran 2018特性，需要替换。

获取指针（通过字节数组绕过类型限制）

function get_pointer() result(usr_ptr)
    use, intrinsic :: iso_c_binding
    implicit none
    class(*), pointer :: usr_ptr
    type(c_ptr) :: cptr
    character(len=:), pointer :: data

    cptr = c_get_pointer()
    call c_f_pointer(cptr, data) ! 将C指针关联到字符指针
    print *, len(data) ! 输出0，但c_loc(data)能返回正确地址
    usr_ptr => data
end function get_pointer

测试代码（在Apple clang 15.0.0 + gfortran 13.2.0下可正常运行）：

implicit none
type(UserData) :: data
type(UserData), pointer :: data_ptr
data = UserData(f = 3.14, i = 42)

call set_pointer(data)
data_ptr => get_pointer()
print *, data_ptr%f ! 输出3.14
print *, data_ptr%i ! 输出42

核心疑问 #

• 该实现是否跨编译器兼容且安全？能否通过这种方式绕过c_f_pointer不能直接配合class(*)的限制？
• 如何将其改为纯Fortran 2003版本（替换type(*)的使用）？
• 能否扩展以解除自定义类型的bind(C)限制？
• 还有哪些潜在问题？

解答 #

1. 当前实现的正确性与安全性 #

这个实现不具备跨编译器兼容性，且存在未定义行为，核心原因：

• c_f_pointer关联到character(len=:), pointer时，Fortran标准要求必须明确指定字符数组的长度（通过第三个shape参数）。你未指定长度，导致data的长度处于未定义状态，当前编译器能工作只是厂商特定的非标准实现。
• 将字符指针转换为class(*), pointer再赋值给特定类型指针，本质是无类型校验的强制内存转换，Fortran标准未定义该操作的合法性。换用其他编译器、优化等级或字节序不同的平台，极可能出现崩溃或错误结果。
• 无法绕过c_f_pointer与class(*)的限制：Fortran标准明确规定c_f_pointer的第二个参数不能是无限多态指针，你的做法是利用字符指针作为中间层的“灰色地带”，不属于标准范畴。

2. 纯Fortran 2003版本实现 #

Fortran 2003没有假定类型（type(*)），可以通过两种方式实现兼容：

方式一：泛型接口重载（类型安全）

针对每个需要支持的bind(C)类型，编写对应的设置/获取过程，通过泛型接口对外统一暴露：

! 对外暴露的泛型接口
interface set_pointer
    module procedure set_pointer_userdata
    ! 为其他需要支持的bind(C)类型添加对应的过程
end interface set_pointer

interface get_pointer
    module procedure get_pointer_userdata
    ! 为其他需要支持的bind(C)类型添加对应的过程
end interface get_pointer

! 针对UserData类型的具体实现
subroutine set_pointer_userdata(data)
    use, intrinsic :: iso_c_binding
    implicit none
    type(UserData), target, intent(in) :: data
    call c_set_pointer(c_loc(data))
end subroutine set_pointer_userdata

function get_pointer_userdata() result(data_ptr)
    use, intrinsic :: iso_c_binding
    implicit none
    type(UserData), pointer :: data_ptr
    type(c_ptr) :: cptr
    cptr = c_get_pointer()
    call c_f_pointer(cptr, data_ptr) ! 直接关联到目标类型指针
end function get_pointer_userdata

这种方式完全符合标准，跨编译器兼容，且用户无需接触iso_c_binding细节。

方式二：通用转换（支持任意bind(C)类型）

如果不想逐个重载类型，可以通过transfer将数据转换为字符数组后获取地址，需要用户传入类型大小：

subroutine set_pointer_generic(data, type_size)
    use, intrinsic :: iso_c_binding
    implicit none
    class(*), target, intent(in) :: data
    integer(c_size_t), intent(in) :: type_size
    type(c_ptr) :: cptr
    ! 将数据转换为对应大小的字符数组，再获取地址
    cptr = c_loc(transfer(data, [character(kind=c_char)::], type_size))
    call c_set_pointer(cptr)
end subroutine set_pointer_generic

注：用户需要手动传入类型大小（如storage_size(data)/8或c_sizeof(data)），稍显繁琐，但符合Fortran 2003标准。

3. 解除bind(C)限制的可能性 #

确实无法安全解除bind(C)限制，原因：

• 非bind(C)的Fortran派生类型可能包含编译器特定的内存布局（如虚函数表、可分配数组描述符、指针额外信息等），这些布局无法与C的void*直接兼容。
• 可分配数组、指针成员等非C互操作特性的元数据不会被c_loc捕获，存储void*后无法恢复完整的Fortran对象状态。
• 强行存储非bind(C)类型的地址，后续转换回来时会丢失类型信息和元数据，必然导致未定义行为。

4. 潜在问题补充 #

• 生命周期管理：必须确保存储的void*指向的Fortran对象在获取时仍然有效（未被销毁或超出作用域），否则会产生悬空指针。
• 类型安全：当前字节数组转换方式没有类型校验，用户错误转换类型会直接导致内存错误；泛型接口方式可在编译期完成类型检查。
• 对齐问题：C和Fortran的内存对齐规则可能存在差异，即使是bind(C)类型，也要确保编译器的对齐选项一致，避免访问未对齐内存导致的性能问题或崩溃。

内容的提问来源于stack exchange，提问作者Gaëtan J.A.M.