实战：使用rust开发动态链接库并在Golang中使用

本篇文章是受Databend团队邀请，作为《Rust培养提高计划》公开课程的讲稿而书写的。

课程相关录像可以在Databend的Bilibili账号【Databend】找到 讲师本人的微信公众号是：【极客幼稚园】 讲师本人的个人博客是: http://blog.ideawand.com 讲师本人的B站账号是: 【爆米花胡了】（注意胡是胡萝卜的胡） https://space.bilibili.com/500416539

特别提示： 该文长 26000+ 字， 阅读时间可能需要超过 60 分钟。 建义先保存收藏观看。  本次分享只是 Rust FFI 中的一部分，其中目录中标灰的内容还没讲到，还会有后续的更新。 可以关注 Databend 公众号了解最新动态。

课程 Demo 代码： https://github.com/myrfy001/rust_golang_ffi_demo 

Rust 培养提高计划回放 :  http://t.cn/A6M4JIOx

分享背景：

• 减弱大家在生产环境中引入Rust的恐惧感，如果你还在犹豫、观望，不妨get your hands dirty first, 然后大家就可以放开了去搞了。
• 了解Rust为什么比一些常用的语言（如Golang、Java等）更适合开发通用二进制库
• 了解一下Rust开发C-FFI库的方法，并介绍一些个人实际使用中遇到的问题（也可能是我太菜）
• 了解一下Golang中Cgo的使用
• 有很多朋友在纠结Golang和Rust选哪个，通过本次分享，加深对两个语言的了解，为大家做选择多一些参考

分享目录

• Get hands dirty
• Rust在开发二进制库上的优势
• 为什么选择Golang作为调用示例
• 配置一个Rust项目，使之能够编译出满足C-FFI的动态链接库
• 开发一个Go项目，调用Rust编写的库
• Case By Case，介绍常见的应用场景
• 字符串的传递
• 结构体以及函数方法
• 回调函数的使用
• FFI接口处的并发安全问题
• 错误处理
• 性能测试：用Rust重写Go模块，真的会更快吗？

目标听众

• 对C语言有大致了解，大学C语言基础就够了
• 熟悉Go、Python、Java这类具有GC的语言，但对C这样需要手工管理内存的语言不熟悉的同学
• 了解Rust，并希望将Rust与其他语言配合使用的同学
• 熟悉Go语言，但不了解cgo使用方法的同学
• 如果你已经熟练掌握的Rust、C/C++、Go，那么这个分享可能过于简单，建议直接Clone Databend的代码，开始为Databend贡献代码~逃~~

Rust在开发二进制库上的优势

• 各种数据结构在内存中是如何布局存储的
• 函数调用时，参数如何传递，返回值如何传递（例如，是用寄存器来传递，还是用栈来传递？）
• 去哪里申请内存空间（使用的内存分配器是什么？），申请使用的内存空间，何时释放，由谁来释放（有没有GC？）？

• A类：是没有虚拟机、运行时，需要开发者自己管理内存的语言，例如C、C++、Rust等。
• B类：是具有虚拟机、具有运行时等协助管理内存的组件的语言，例如Java、Golang、Python、PHP等。

from ctypes import cdll, c_char, c_char_p

libc = cdll.LoadLibrary('libc.so.6')
strchr = libc.strchr
strchr.argtypes = [c_char_p, c_char]
strchr.restype = c_char_p

substr = strchr('abcdef', 'd')
if substr:
    print(substr)
复制

• 根据第5行指定的入参类型，把两个Python字符串对象转换为C语言的char *
  和char
  类型，对于char *
  类型，需要确保其指向的字符串是以NULL结尾的。
• 根据转换后的参数调用C函数库
• 根据第6行定义的返回值类型，将C函数返回的一个字节的char
  类型结果，重新转换为换一个str
  类型的Python对象

• A类中的语言相互调用，往往是最原生、最高效的。
• B类中的语言相互调用，往往伴随着巨大的额外开销，甚至开销过大以至于失去折腾这些跨语言调用的价值。
• 每种语言都可能处于调用者和被调用者两种角色，而一门语言扮演两种角色时，其支持程度可能是不一样的：
• B类语言通常都支持调用A类语言开发的库函数，而且开销相对较小，因为B类语言通常比较新，为了适配老生态，他们都会去主动靠拢支持与C语言开发的库的调用。
• A类语言如果想调用B类语言开发的函数，就要看B语言的诚意，因为A类语言是前辈，它们对新的语言特性、实现方式一无所知，后辈们如果希望得到前辈的重用，那就要自己提供出满足前辈价值观的接口。
• 通常，B类调用A类会容易实现一些（只需要做类型转换），而A类调用B类则会困难一些（需要初始化B类语言的运行时、解释器等）。多数语言对B类调A类的支持会优于A类调B类。

为什么选择Golang作为调用示例

• Golang 目前应用非常广泛，熟悉Golang的小伙伴们也比较多，这样可能会有更多的受众。
• 最近使用Rust或Go开发的云原生项目增长非常快，因为这两种语言的应用场景在云原生方面有重合，所以研究一下二者的融合就很有意思。
• Golang 具有自己的运行时、自己的栈结构、自己的内存分配器，因此相比较于Python这类胶水语言，Golang调用CFFI函数库更有难度，我们喜欢做一些有挑战的事情。
• 正因为其略微复杂，我们才可以更好的思考一些问题，更好的领会跨语言调用的核心思想。

配置一个Rust项目，使之能够编译出满足C-ABI的动态链接库

.
├── Cargo.lock
├── Cargo.toml
└── src
    ├── ffi.rs
    ├── lib.rs
    └── my_app.rs
复制

[lib]
crate-type = ["cdylib"]
复制

• my_app.rs
  代表的是我们编写普通Rust代码的地方，我们开发的主要Rust逻辑都写在这个文件中。这只是一个案例，在真实项目中，my_app.rs
  对应的可能是一个包含数百个源代码文件的庞大的Rust项目。
• ffi.rs
  是我们的FFI边界，在这个文件中，我们要把Rust提供的各种高级特性适配到经典的C-FFI形式的函数上。
• lib.rs
  是我们整个库的入口，里面只有两行mod
  声明语句，用于引入my_app.rs
  和ffi.rs
  

pub fn my_app_simple_rust_func_called_from_go(arg1: u8, arg2: u16, arg3: u32) -> usize {
  arg1 as usize + arg2 as usize + arg3 as usize
}
复制

use crate::my_app;

#[no_mangle]
fn simple_rust_func_called_from_go(arg1: u8, arg2: u16, arg3: u32) -> usize {
    my_app::my_app_simple_rust_func_called_from_go(arg1, arg2, arg3) as usize
}
复制

开发一个Go项目，调用Rust编写的库

本篇文章虽然是介绍在Go中调用Rust编写的函数库，但其中以C-FFI为界，在Golang视角中，其看到的只是一个符合C-FFI标准的函数库，本篇文章介绍的与cgo有关的知识点，可以应用在其他任何语言所开发的符合C-FFI标准的软件库上，不仅限于Rust开发的软件库。

.
├── ffi_demo.h
├── go.mod
├── main.go
└── main_test.go
复制

#include "stdint.h"

uintptr_t simple_rust_func_called_from_go(uint8_t arg1, uint16_t arg2, uint32_t arg3);
复制

为了简洁明了，这个头文件是我手写的，写的并不是很规范，对于一个大项目，自己手写头文件比较坑，可以使用cbindgen
这个工具来自动生成，有兴趣的同学可以自己去学习一下。

• 首先标明函数的返回值类型是一个与处理器位宽一致的数据类型。
• 接下来是函数名，这个函数名必须与rust中添加了#[no_mangle]
  标签的函数名一直，因为在链接器链接的过程中，通过符号表查找函数地址的时候，就要靠这个名字
• 后面括号中依次写出了每一个参数的类型，这个类型也一定是和rust中声明的函数签名一致的，只不过它是用C语言的语法来书写的。

package main

/*
#cgo CFLAGS: -I.
#cgo LDFLAGS: -L../rust/target/debug -lrust

#include "ffi_demo.h"
*/
import "C"


func SimpleRustFuncCalledFromGo() {
  arg1 := 123
  arg2 := 1234
  arg3 := 1234567

  cArg1 := C.uint8_t(arg1)
  cArg2 := C.uint16_t(arg2);
  cArg3 := C.uint32_t(arg3);
  ret := C.simple_rust_func_called_from_go(cArg1, cArg2, cArg3)
  if int(ret) != arg1 + arg2 + arg3 {
    panic("SimpleRustFuncCalledFromGo Error")  
  }
}
复制

• #cgo CFLAGS: -I.
  这一行表示告诉C【编译器】，增加一个搜寻头文件的路径，这里的-I.
  中的.
  表示当前路径，而后面我们在启动测试程序是，就是将golang
  这个目录作为当前工作目录，我们的ffi_demo.h
  这个文件也就放在工作目录中，这样编译器就能在当前目录下搜索到ffi_demo.h
  了。
• #cgo LDFLAGS: -L../rust/target/debug -lrust
  这一行告诉C【链接器】两件事：
• -L../rust/target/debug
  表示要增加一个库文件的搜索路径
• -lrust
  表示要搜索一个叫做rust
  的库文件，按照*nix的规范，实际上就是查找一个叫做librust.so
  的文件
• #include "ffi_demo.h"
  这一行就是一段标准的C语言代码，指示C语言编译器引用ffi_demo.h
  文件中编写的代码。

广告时间：如果大家对*nix系统下动态库的查找方式感兴趣，可以阅读笔者的另一篇文章：《一文读懂Linux下动态链接库版本管理及查找加载方式》

• 前三行定义了3个go变量，其类型都是int类型
• 接下来三行，我们从这三个go变量创建了3个调用C库时需要使用的变量，之所以这样做，是因为arg1
  、arg2
  、arg3
  这三个变量在go中默认都是int类型的，也就是说其所占用的内存空间都是与处理器位宽一致的，而我们在ffi_demo.h
  中定义的三个参数，分别只占用1、2和4个字节，因此我们需要做一下类型的转换，得到了cArg1
  、cArg2
  、cArg3
  这三个变量，其类型分别是C.uint8_t
  、C.uint16_t
  、C.uint32_t
  。
• 再下面的一行，通过C.simple_rust_func_called_from_go
  的形式，表示我们要通过cgo来调用一个外部C库中名为simple_rust_func_called_from_go
  的函数：
• 之所以我们能通过C
  这个模块来访问simple_rust_func_called_from_go
  ,是因为我们在代码第7行加载了ffi_demo.h
  ,而simple_rust_func_called_from_go
  定义在ffi_demo.h
  中。
• 在编译链接时，链接器需要在多个指定的外部候选库中寻找需要链接的函数，由于我们在第5行告诉链接器要添加一个名为librust.so
  的文件作为可能要被链接的候选，而这个库文件的符号表中恰好暴露了一个名为simple_rust_func_called_from_go
  的函数，于是链接器就知道当要调用这个函数的时候，要把PC指针跳转到librust.so
  这个动态库内部对应的地址上。
• librust.so
  之所以会暴露simple_rust_func_called_from_go
  这个符号，是因为我们在写rust代码的时候添加了#[no_mangle]
  标签
• 这个函数调用执行完以后，其返回被存到了ret这个变量中，这个变量的类型是C.ulong
  ,为了将C.ulong
  与go的内置int类型进行比较，我们需要再做一次类型转换。
• 这里可以稍微注意一下，我们在ffi_demo.h
  中定义了函数的返回值类型是C语言中的uintptr_t
  ，这个类型对应到cgo中变为了C.ulong
  类型。在跨越FFI边界的时候，类型神马的已经完全不存在了。数据也好，指针也罢，无非就是一串特定的二进制比特序列而已，类型系统告诉编译器如何处理使用这一段比特序列。
• 至于为什么ffi_demo.h
  文件中定义的uintptr_t
  会变为cgo中的C.ulong
  ，这个大家也没必要死记硬背，我们可以借助编译器的错误提示信息来获取到底是什么类型。比如以后你遇到了一个不知道是什么类型的东西，那就人为制造一个类型不匹配，编译器会给出响应的提示。例如，我们可以把上面的if int(ret) != arg1 + arg2 + arg3 {
  这一行改为if ret != arg1 + arg2 + arg3 {
  ,编译器就会提示无法将C._Ctype_ulong
  和int
  做比较，这时候我们就知道ret对应的类型实际上是C.ulong
  了

通过cgo调用c函数时，参数都要使用C
这个模块内部提供的类型。而返回值也一定是C
模块内定义的某种类型

字符串的传递

预防针 在接下来的内容中，会遇到一些非常规的做法，这里之所以要介绍这些非常规的做法，目的不是为了鼓励大家在代码中去这么使用，而是给大家展示各种各样的情况，让大家了解到无论上层接口再怎么变，使用方法再怎么稀奇古怪，其底层核心不变的就是内存的分配与释放。借助unsafe rust，大家可以获得像C/C++一样对内存的完全掌控能力。实际使用中FFI边界上的情况非常灵活多变，但只要内存管理能搞清楚，其他的事情都不是大问题。

了解库函数的核心功能逻辑

pub fn my_app_receive_string_and_return_string(s: String) -> String {}

pub fn my_app_receive_str_and_return_string(s: &str) -> String {}

pub fn my_app_receive_str_and_return_str(s: &str) -> &str {}

pub unsafe fn my_app_receive_string_and_return_str<'a>(s: String) -> (&'a str, *const u8, usize, usize) {}
复制

• 当输入字符串的长度小于15个byte的时候，返回完整的字符串，而超过15个byte的时候返回前15个byte

接收String，返回String

pub fn my_app_receive_string_and_return_string(s: String) -> String {
  if s.len() > 15 {
    // this path has new memory alloc on heap
    s[0..15].to_string()
  } else {
    // this path doesn't have new memory alloc on heap
    s
  }
}
复制

                    old:
                   ┌───┬───┬───┐
                   │ptr│cap│len│
                   ├───┼───┼───┤
                   │   │ 19│ 19│
                   └─┬─┴───┴───┘
  new:               │
┌───┬───┬───┐        │
│ptr│cap│len│        │
├───┼───┼───┤      ┌─┴┬──┬──┬──┬──┬──┬──┬──┬──┬──┬──┬──┬──┬──┬──┬──┬──┬──┬──┐
│   │ 15│ 15│      │0 │1 │2 │3 │4 │5 │6 │7 │8 │9 │A │B │C │D │E │F │X │Y │Z │
└─┬─┴───┴───┘      └──┴──┴──┴──┴──┴──┴──┴──┴──┴──┴──┴──┴──┴──┴──┴──┴──┴──┴──┘
  │
  │                ┌──┬──┬──┬──┬──┬──┬──┬──┬──┬──┬──┬──┬──┬──┬──┐
  └───────────────►│0 │1 │2 │3 │4 │5 │6 │7 │8 │9 │A │B │C │D │E │
                   └──┴──┴──┴──┴──┴──┴──┴──┴──┴──┴──┴──┴──┴──┴──┘
复制

                      old:
                     ┌───┬───┬───┐
 new:                │ptr│cap│len│
┌───┬───┬───┐        ├───┼───┼───┤
│ptr│cap│len│        │   │ 15│ 15│
├───┼───┼───┤        └─┬─┴───┴───┘
│   │ 15│ 15│          │
└─┬─┴───┴───┘          │
  │                    ▼
  │                  ┌──┬──┬──┬──┬──┬──┬──┬──┬──┬──┬──┬──┬──┬──┬──┐
  └─────────────────►│0 │1 │2 │3 │4 │5 │6 │7 │8 │9 │A │B │C │D │E │
                     └──┴──┴──┴──┴──┴──┴──┴──┴──┴──┴──┴──┴──┴──┴──┘
复制

出于篇幅的限制，后面不能每个case都画图来说明。在继续后面的介绍之前，大家一定要理解这个字符串在内存中的表示形式，并且在看到后面的代码时，能想想出对应的内存布局。

接收&str，返回String

pub fn my_app_receive_str_and_return_string(s: &str) -> String {
  // both path alloc new memory
  if s.len() > 15 {
    s[0..15].to_string()
  } else {
    s.to_string()
  }
}
复制

 String:        &str:
┌───┬───┬───┐  ┌───┬───┐
│ptr│cap│len│  │ptr│len│
├───┼───┼───┤  ├───┼───┤
│   │ 15│ 15│  │   │ 3 │
└─┬─┴───┴───┘  └─┬─┴───┘
  │              │
  │              │
  ▼              ▼
┌──┬──┬──┬──┬──┬──┬──┬──┬──┬──┬──┬──┬──┬──┬──┐
│0 │1 │2 │3 │4 │5 │6 │7 │8 │9 │A │B │C │D │E │
└──┴──┴──┴──┴──┴──┴──┴──┴──┴──┴──┴──┴──┴──┴──┘
复制

接收&str，返回&str

pub fn my_app_receive_str_and_return_str(s: &str) -> &str {
  // neither path alloc new memory
  if s.len() > 15 {
    &s[0..15]
  } else {
    s
  }
}
复制

接收String，返回&str

pub unsafe fn my_app_receive_string_and_return_str<'a>(s: String) -> (&'a str, *const u8, usize, usize) {
  // this function is only used as an example to show that we can use unsafe 
  // rust to turn an owned type to a reference, you should not write such code
  // in production code. It's a very ugly api design.


  // neither path alloc new memory
  let my_slice = if s.len() > 15 {
    &*(&s[0..15] as &str as *const str)
  } else {
    &*(&s as &str as *const str)
  };

  // you can replace the following two lines using s.into_raw_parts()
  // s.into_raw_parts() internally use ManuallyDrop too
  // I use ManuallyDrop explicit here to show you how memory is managed
  // The reason why we need to return the ptr, len and cap is that we need them
  // to rebuild the String header, we need to rebuild the string header to 
  // free memory.
  let s = ManuallyDrop::new(s);  
  (my_slice, s.as_ptr(), s.len(), s.capacity())
}
复制

包装字符串传递的FFI接口

#[no_mangle]
pub fn receive_str_and_return_string(s: *const c_char) -> *const c_char{}

#[no_mangle]
pub fn receive_string_and_return_string(s: *const c_char) -> *const c_char{}

#[no_mangle]
pub fn receive_str_and_return_str(s: *const c_char) -> *const c_char{}

#[no_mangle]
pub fn receive_string_and_return_str(s: *const c_char, new_ptr: *mut *const c_char, c_origin_ptr: *mut *const c_char, len: *mut usize, cap: *mut usize){}

#[no_mangle]
pub unsafe fn free_string_alloc_by_rust_by_raw_parts(s: *mut c_char, len: usize, cap: usize){}

#[no_mangle]
pub unsafe fn free_cstring_alloc_by_rust(s: *mut c_char){}

#[no_mangle]
pub fn receive_str_and_return_str_no_copy(s: *const c_char, new_ptr: *mut *const c_char, len: *mut usize){}
复制

┌────────────────────┐              ┌────────────────────┐
│s1="0123456789A"    │              │s3="CDEF"           │
└┬───────────────────┘              └─┬──────────────────┘
 │                                    │
 │          ┌────────────────────┐    │         ┌───────┐
 │          │s2="456789A"        │    │         │s4=""  │
 │          └┬───────────────────┘    │         └┬──────┘
 │           │                        │          │
 │           │                        │          │
 ▼           ▼                        ▼          ▼
┌──┬──┬──┬──┬──┬──┬──┬──┬──┬──┬──┬──┬──┬──┬──┬──┬──┬──┬──┐
│0 │1 │2 │3 │4 │5 │6 │7 │8 │9 │A │\0│C │D │E │F │\0│Y │Z │
└──┴──┴──┴──┴──┴──┴──┴──┴──┴──┴──┴──┴──┴──┴──┴──┴──┴──┴──┘
复制

• String
  头占3个字长，&str
  胖指针占2个字长，char*
  指针占1个字长
• String
  和&str
  里面都有长度记录，可以O(1)复杂度获取长度，而char*
  要从头开始数，是O(N)复杂度
• String
  和&str
  所指向的字节序列一定是满足UTF-8编码的字符串（Rust规范），而char*
  里面存储的可以是任何字符编码（UTF-8、GBK、ASCII等等），甚至可以是非字符编码，比如一段任意的二进制数据，只要中间没有Null字节出现即可。
• String
  和&str
  可以在中间出现Null字节，但是char*
  中间不可以，一旦出现就代表着字符串到这里结束了。

• CString
  对应的是String
  ，用来表示具有堆内存所有权的字符串，但内容是满足C字符串标准的，也就是说内容不一定是UTF-8编码的，且一定没有Null。
• CString
  通常用来在Rust一侧分配堆内存后，把Rust生成的字符串传递给外部系统使用，堆内存所有权在Rust手里，后续要由Rust来释放。
• CStr
  对应的就是str
  ，他同样是一个DST类型，因此通常以&CStr
  的形式出现，表示对一段内存地址的引用，其内部存储的数据也不一定是UTF-8编码的，也一定在中间没有Null。
• CStr
  通常表示外部传入的字符串，字符串对应的内存空间所有权在外部系统，Rust的代码只能临时借用，而不是拥有。

receive_str_and_return_string:

#[no_mangle]
pub fn receive_str_and_return_string(s: *const c_char) -> *const c_char {
    let cstr = {
        // 永远要记得先检查传入的指针是不是空指针
        assert!(!s.is_null());
        // 下面这一行内部实现会遍历s，寻找第一个Null出现的位置，说白了就是做计数，数出来字符串的长度
        // &CStr 相比于 *const c_char而言，内部直接记录了长度信息
        // 由于我们要读裸指针，所以需要一个unsafe块
        unsafe{CStr::from_ptr(s)}
    };

    // 下面这一行会再一次遍历底层的字节序列来检查一下这个字节序列是否满足UTF-8编码，如果检查通过，这个
    // 函数会返回一个&str类型的指针，同样指向原来的地址。这一步相当于做了一个认证，把`&CStr`转换为`&str`
    // 就可以告诉类型系统：这块内存满足我们Rust对字符串的要求，可以在Safe Rust代码里放心使用了。
    // 这个操作会复用底层的字节数组，不会发生内存分配和数据拷贝。
    // 由于`&str`是一个引用，它引用的是外部系统（例如Golang）所持有的内存，所以，外部系统必须有责任保证这
    // 块内存不会在使用中被释放
    let rstr = cstr.to_str().expect("not valid utf-8 string");

    // 上面的两行代码没有做内存分配，但是却从头到尾遍历了两次字符串。如果这个FFI接口在你的Hot Path上，那么
    // 你需要认真考虑一下性能开销的影响。

    // 现在，我们就可以在Safe Rust的世界来使用外部的字符串了
    let ret = my_app::my_app_receive_str_and_return_string(rstr);

    // 现在，我们得到了一个`String`，这也就意味着上面的函数调用过程中发生了Rust这一侧的内存分配。
    // 我们将要返回给调用者一个指针，但返回的数据必须遵循C的字符串规范才能够穿越FFI的边界，也就是我们
    // 要返回一个裸指针，裸指针本身没有字符串的长度信息，并且指向一块以Null结尾的内存区域。
    // 而我们知道，Rust的String不一定能保证字符串结尾的后面一定有一个Null存在。
    // 这时我们就要借助`CString`这个数据类型了，不幸的是，这里又会引入额外的开销：
    // * 首先，它会再次检查整个底层字节数组是否在中间包含Null，因此它会再次遍历字符串。
    // * 其次，它将尝试将 Null字节追加到底层数组的后面，这一步是否会有额外开销取决于底层的缓冲区
    //   是否还有空闲空间，也就是String的len是否小于cap。如果有空间，那么追加一个Null字节几乎
    //   没有什么开销，但如果没有空间，那么就要进行扩容操作，这会导致一次内存分配以及一次数据拷贝
    let c_ret = CString::new(ret).expect("null byte in the middle");

    // 终于到了这里，我们可以通过into_raw()的方法返回一个指向堆内存的指针了。这个方法会消耗掉
    // c_ret，让编译器暂时“忘掉”这块堆内存。
    // 但是，这块内存迟早要有人来释放，应该怎么释放呢？我们后面再介绍。
    c_ret.into_raw()

    // 重要提示：
    // 看完上面的代码，你必须要掌握的一个核心点：
    // * 这个ffi包装函数的入参所对应的内存是由调用者拥有的（比如Golang），因此也必须由外部系统
    //   来决定何时释放
    // * 返回值是由Rust申请的，那么将来也一定是由Rust来执行释放
}

复制

• 通过人为的约定，减少一些不必要的检查
• 通过调整API接口的设计，显式传递字符串长度
• 通过调整API接口设计，将频繁的调用转化为少量批次调用，以减小开销
• 避免在Hot Path上使用转换开销大的接口 关于提升性能，我们会在文章后后面进一步讨论，通过做性能测试的方法，来对比不同方案的性能提升。

receive_string_and_return_string:

#[no_mangle]
pub fn receive_string_and_return_string(s: *const c_char) -> *const c_char {
    let cstr = {
        assert!(!s.is_null());
        unsafe{CStr::from_ptr(s)}
    };

    // to_str() 会遍历一次String来检查是否满足UTF-8，to_string() 会分配一次内存并且做一次拷贝。所以下面这行代码总计会有两次长度为N的遍历以及一次内存分配
    let r_string = cstr.to_str().expect("not valid utf-8 string").to_string();

    // 下面这一行调用，根据传入的字符串长度，可能进行内存分配，也可能不进行分配。
    let ret = my_app::my_app_receive_string_and_return_string(r_string);

    let c_ret = CString::new(ret).expect("null byte in the middle");
    c_ret.into_raw()
    
    // 重要提示：
    // 和上一个函数一样，输入数据的内存是被Golang持有的，返回值是被Rust持有的
    // 返回的指针指向c_ret申请的的堆内存，该段内存因为into_raw()方法，暂时被编译器忘掉，函数返回时不会被释放
    // r_string 和 ret 都是临时变量, 最终返回的字符指针指向的堆内存地址是c_ret变量持有的，
    // r_string 和 ret 所分配的堆内存都会在函数返回时被回收。
}
复制

receive_str_and_return_str

#[no_mangle]
pub fn receive_str_and_return_str(s: *const c_char) -> *const c_char {    
    let cstr = {
        assert!(!s.is_null());
        unsafe{CStr::from_ptr(s)}
    };

    let rstr = cstr.to_str().expect("not valid utf-8 string");

    // 下面这个函数调用并不会进行内存分配，从Rust角度来看，&str是要复用底层的字符缓冲区，
    // 这样看起来貌似很好，没啥问题
    let ret = my_app::my_app_receive_str_and_return_str(rstr);

    // 但是，问题来了，如果上面的函数调用返回的是一个长字符串的子切片，那么这个子切片就不会是以Null结尾的了，
    // 因为&str是一个Rust概念里的胖指针，里面存了长度，所以这对Rust不是个问题。但在FFI的边界上，我们要
    // 使用C语言规范来交流，所以这就成了一个大问题。因此，我们还是需要再创建一个CString，于是又引入了
    // 内存分配和拷贝。
    let c_ret = CString::new(ret).expect("null byte in the middle");
    c_ret.into_raw()

    // 重要提示：
    // 这是一个用来演示Rust在FFI边界上处理字符串引用所引入的开销的例子。在纯Rust中，
    // `my_app::my_app_receive_str_and_return_str(str)`这个函数的参数和返回值都是引用
    // 类型，所以我们可以避免数据的复制。
    // 但是在FFI的边界上，根据FFI包装函数实现方式的不同，返回值可能可以复用内存，避免拷贝，
    // 也可能需要重新分配内存并拷贝。
    // 在我们当前的这个例子的实现中，我们就无法避免拷贝。如果你想避免拷贝，那么就要重新设计FFI
    // 接口的API样式。（我们会在后面的例子中给出例子）
    // 作为这个函数库的作者，你有责任编写一个清晰的使用手册来告诉用户，输入数据与输出数据的内存
    // 是怎样被使用的。
    // 最后，和上一个函数一样，输入数据的内存是被Golang持有的，返回值是被Rust持有的
    // 返回的指针指向c_ret申请的的堆内存，该段内存因为into_raw()方法，暂时被编译器忘掉，函数返回时不会被释放
}
复制

receive_string_and_return_str

• 定义一个结构体来保存多个返回值的内容，然后返回指向这个结构体的指针
• 通过传入指针来修改调用者的内存数据，从而将要返回的值写入到调用者给定的变量中 这里我们的二阶指针就是使用了第二种方法。

#[no_mangle]
pub fn receive_string_and_return_str(s: *const c_char, new_ptr: *mut *const c_char, c_origin_ptr: *mut *const c_char, len: *mut usize, cap: *mut usize) {
    let cstr = {
        assert!(!s.is_null());
        unsafe{CStr::from_ptr(s)}
    };

    let r_string = cstr.to_str().expect("not valid utf-8 string").to_string();

    
    let (ret, t_c_origin_ptr, t_len, t_cap) = unsafe{my_app::my_app_receive_string_and_return_str(r_string)};


    let c_ret = CString::new(ret).expect("null byte in the middle");
    unsafe {
        *new_ptr = c_ret.into_raw();
        *c_origin_ptr = t_c_origin_ptr as *const i8;
        *len = t_len;
        *cap = t_cap;
    }

    // 重要提示：
    // 和上一个函数一样，输入数据的内存是被Golang持有的，返回值是被Rust持有的
    // 返回的指针指向c_ret申请的的堆内存，该段内存因为into_raw()方法，暂时被编译器忘掉，函数返回时不会被释放
    // ret是一个临时变量
    // ret 和 t_c_origin_ptr 都指向r_string申请到的堆内存
    // 由于在`my_app::my_app_receive_string_and_return_str()`这个函数内部，我们也让编译器忘掉了r_string申请
    // 的堆内存，所以在函数返回时，r_string申请的内存不会被释放，c_origin_ptr所指向的内存就还是有效可用的内存
}
复制

内存释放的相关函数

#[no_mangle]
pub unsafe fn free_string_alloc_by_rust_by_raw_parts(s: *mut c_char, len: usize, cap: usize) {
  String::from_raw_parts(s as *mut u8, len, cap);
}

#[no_mangle]
pub unsafe fn free_cstring_alloc_by_rust(s: *mut c_char) {
  // 这个方法会再次遍历指针所指向的内存，直到找到Null，从而计算出字符串的长度
  CString::from_raw(s);
}
复制

一个零拷贝的FFI接口示例

#[no_mangle]
pub fn receive_str_and_return_str_no_copy(s: *const c_char, new_ptr: *mut *const c_char, len: *mut usize) {
    let cstr = {
        assert!(!s.is_null());
        unsafe{CStr::from_ptr(s)}
    };

    let rstr = cstr.to_str().expect("not valid utf-8 string");
    let ret = my_app::my_app_receive_str_and_return_str(rstr);
    let c_ret = ret.as_ptr();

    unsafe {
        *new_ptr = c_ret as *const i8;
        *len = ret.len();
    }

    // 重要提示：
    // 在这段代码中没有出现任何`to_owned()` 或 `to_string()`，因此这个API接口不会申请任何新的堆内存
    // 我们显示返回了字符串的长度，这样就解决了截取字符串末尾没有Null的问题。
    // 返回的指针所指向的内存，是外部系统分配的内存空间，不是Rust分配的！！！
    // 如果你设计了一个这样的API接口，那么你应该在说明文档中清楚地写出来，返回的内存指针是指向了调用者提供的内存
}
复制

在Golang中调用

#include "stdint.h"

uintptr_t simple_rust_func_called_from_go(uint8_t arg1, uint16_t arg2, uint32_t arg3);

char* receive_str_and_return_string(char*);
char* receive_string_and_return_string(char*);
char* receive_str_and_return_str(char*);
// the follow line is a very ugly api design, only used as example, never use in real code.
char* receive_string_and_return_str(char*, char**, char**, uintptr_t*, uintptr_t*);

void free_string_alloc_by_rust_by_raw_parts(char*, uintptr_t, uintptr_t);
void free_cstring_alloc_by_rust(char*);

void receive_str_and_return_str_no_copy(char*, char**, uintptr_t*);
复制

  testProc := func(f int, x, y string) {
    goStr := x

    // Memory Alloc in OS allocator And String Copy
    // cStr is not managed by go GC
    cStr := C.CString(goStr)
    defer C.free(unsafe.Pointer(cStr))
  
    var cStrRet *C.char
    switch f{
    case 1:
      cStrRet = C.receive_str_and_return_string(cStr)
    case 2:
      cStrRet = C.receive_string_and_return_string(cStr)
    case 3:
      cStrRet = C.receive_str_and_return_str(cStr)
    }
    
    // Memory Alloc in Go runtime And String Copy
    // goStrRet is managed by go GC
    goStrRet := C.GoString(cStrRet) 
    C.free_cstring_alloc_by_rust(cStrRet)

    if goStrRet != y {
      panic(fmt.Sprintf("Error, expected %s, got %s", y, goStrRet))  
    }
  }
复制

• 由于函数签名相同，我们用这一个函数来测试三个Rust暴露出来的函数，通过第一个参数来选择调用哪个rust函数。
• C.CString()
  和 C.GoString()
  两个内置函数分别用于实现C和Go字符串的相互转换，这里的原理和Rust的原理类似，就不再展开讲了，需要注意的是，这两个函数调用都会导致内存分配和内存拷贝。
• 因为Go是有垃圾回收的，GoString所对应的内存地址是在Go Runtime的内存分配器管辖范围里的，而cgo中为了实现CFFI的调用，需要使用操作系统的内存分配器，Go语言中这两个内存分配器对内存管理的方式不一样，其内存地址区间也不一样，因此需要内存分配与拷贝。
• C.free()
  调用的是操作系统默认内存分配器的free方法，用来释放掉Go语言通过操作系统内存分配器分配的内存。这部分内存不受Go语言垃圾回收的管理，因此需要手动释放，否则就会内存泄漏。
• Rust函数调用完成后，Rust返回了一个指向Rust分配的内存的指针，这部分内存必须由Rust来释放，因此需要再调用一下Rust库暴露出来的释放接口。

  testProc(1, "极客幼稚园是一个不错的微信公众号", "极客幼稚园")
  testProc(1, "Datafuse Lab", "Datafuse Lab")

  testProc(2, "极客幼稚园是一个不错的微信公众号", "极客幼稚园")
  testProc(2, "Datafuse Lab", "Datafuse Lab")

  testProc(3, "极客幼稚园是一个不错的微信公众号", "极客幼稚园")
  testProc(3, "Datafuse Lab", "Datafuse Lab")
复制

  testProc := func(x, y string) {
    goStr := x
    cStr := C.CString(goStr)  // Memory Alloc And String Copy
    defer C.free(unsafe.Pointer(cStr))
  
    var cStrRet *C.char
    var cRawStr *C.char
    retCap := C.ulong(0)
    retLen := C.ulong(0)

    C.receive_string_and_return_str(cStr, &cStrRet, &cRawStr, &retLen, &retCap)
    
    
    goStrRet := C.GoString(cStrRet)  // Memory Alloc And String Copy
    C.free_string_alloc_by_rust_by_raw_parts(cStrRet, retLen, retCap)

    if goStrRet != y {
      panic(fmt.Sprintf("Error, expected %s, got %s", y, goStrRet))  
    }
  }
复制

testProc := func(x, y string) {
    goStr := x
    cStr := C.CString(goStr)  // Memory Alloc And String Copy
    defer C.free(unsafe.Pointer(cStr))
  
    var cStrRet *C.char
    retLen := C.ulong(0)

    C.receive_str_and_return_str_no_copy(cStr, &cStrRet, &retLen)
    
    goStrRet := C.GoString(cStrRet)  // Memory Alloc And String Copy
    // 注意：不同于前面的Go代码，我们在创建完GoString以后，不能在这里调用Rust提供的内存释放接口了
    // 因为cStrRet所指向的内存就是上面cStr所分配的内存，这段内存会被上面的defer语句在函数返回时释放
    // 如果我们在这里释放，就会导致内存的二次释放问题。

    // 因为是复用的同一块内存，所以重构出来的Go字符串会和输入的字符串一模一样。因为我们并不能向字符串中间插入Null
    if goStrRet != x {
      panic(fmt.Sprintf("Error, expected %s, got %s", x, goStrRet))  
    }

    // 但是，通过Rust函数返回的长度信息，我们截取出来我们要的数据
    goStrRetWithLengthLimit := goStrRet[:retLen]
    if goStrRetWithLengthLimit != y {
      panic(fmt.Sprintf("Error, expected %s, got %s", y, goStrRetWithLengthLimit))  
    }

    // 我们的演示案例中，由于没有修改字符串的起始位置，只是调整了它的结尾，所以API返回新的字符串指针其实是有些多余的，使用原始的传入字符串
    // 当然也可以打到效果，毕竟我们只需要知道一个长度而已。但是如果这个函数的功能是从字符串的中间截取一段出来的话，那么返回一个子字符串的起
    // 始指针就很重要了。
    if goStr[:retLen] != y {
      panic(fmt.Sprintf("Error, expected %s, got %s", y, goStrRetWithLengthLimit))  
    }
  }
复制