使用std::ptr::addr_of_mut!调用FFI栈变量触发段错误的原因

你的第一种写法出现段错误的核心原因是手动定义的Termios结构体与系统C库中的实际struct termios布局/大小不匹配，尤其是c_cc数组的长度NCCS定义错误，导致tcgetattr写入时栈内存越界，破坏了栈上的关键数据（比如函数返回地址），最终在后续返回时触发段错误。

具体原因拆解 #

1. 结构体大小不匹配导致栈越界
   系统C库的struct termios中，c_cc数组的长度由NCCS宏决定，这个值在不同系统（比如Linux、BSD）甚至同一系统的不同架构下都可能不同（例如Linux x86_64下NCCS是32，而某些BSD变种是20）。

• 如果你Rust代码中定义的NCCS比系统实际值小，那么Rust分配的Termios栈空间会比C库预期的更小。当tcgetattr向这个结构体写入完整的终端属性数据时，就会超出Rust变量的栈空间，覆盖栈上的其他数据（比如函数返回地址、其他局部变量），直接破坏栈结构。
• 而你用Termios::default()初始化变量时，只是给结构体的每个字段赋了默认值，但并没有改变结构体的实际大小，所以这个初始化操作本身不会解决大小不匹配的问题。

2. 为什么MaybeUninit版本能正常运行？
   这其实是巧合或者暂时的“正常”：MaybeUninit只是分配了对应Rust结构体大小的未初始化内存，并没有改变结构体大小不匹配的问题。可能是这个版本中，栈上该变量后面的内存刚好没有关键数据，暂时没触发崩溃，但这种写法依然存在内存越界的风险，属于不安全的行为。

解决方法 #

• 正确匹配系统的NCCS值：不要手动硬编码NCCS，可以通过查看系统头文件（比如/usr/include/termios.h）找到对应的值，或者根据系统架构用#[cfg]条件编译定义正确的常量。例如Linux下可以定义：

#[cfg(target_os = "linux")]
const NCCS: usize = 32;

• 直接使用标准库绑定：虽然你说在自行学习，但实际项目中推荐使用libc crate提供的libc::termios结构体，它已经为不同系统做了正确的布局适配，完全避免手动定义的错误。

补充验证 #

你可以通过打印Rust结构体的大小和C库中struct termios的大小来验证：

// Rust侧大小
println!("Rust Termios size: {}", std::mem::size_of::<Termios>());

// C侧大小，通过FFI调用获取
extern "C" {
    fn termios_size() -> usize;
}
// 对应的C代码（编译成静态库供Rust调用）：
// #include <termios.h>
// size_t termios_size() { return sizeof(struct termios); }

如果两者数值不一致，就确认是结构体大小不匹配的问题。

内容的提问来源于stack exchange，提问作者Florian