读完 Rust 1.99.1，我把学习清单缩成了一个 FFI 回归例

十月版本公告里，我最想追问的不是“又快了多少”，而是一个bool返回值为什么值得修复。2026-10-15的Rust 1.99.1公告说明：x86_64上的FFI bool返回值曾存在高位未正确零扩展的问题。该结论来自官方修复说明，本文没有复现那个编译器缺陷。

bool 不只是源代码里的 true 和 false

跨ABI边界，调用者按约定读取寄存器和类型表示。即使Rust函数内部的逻辑只有一个比较，返回值如何交付给C调用者仍依赖编译器遵守目标ABI。只从Rust调用Rust函数，不足以检查这条边界。

我把学习任务缩成两个文件。Rust文件main.rs如下，既能单独检查函数逻辑，也能编译成动态库：

#[unsafe(no_mangle)]
pub extern "C" fn rust_is_even(x:u8)->bool { x%2==0 }
fn main(){
    for x in 0..=255u8 {assert_eq!(rust_is_even(x),x%2==0);}
    println!("local bool function: 256 values checked");
}

C文件caller.c如下，使用stdint.h与stdbool.h中的类型声明：

#include <stdint.h>
#include <stdbool.h>
#include <assert.h>
#include <stdio.h>
extern bool rust_is_even(uint8_t x);
int main(void) {
    for (unsigned i=0;i<256;i++)
        assert(rust_is_even((uint8_t)i)==(i%2==0));
    puts("C to Rust bool: 256 values checked");
    return 0;
}

本地能验证哪一部分

在macOS aarch64，Rust 1.98.0和本机Apple Clang上，先运行Rust断言，再执行：

rustc --edition=2024 --crate-type=cdylib main.rs -o libbool_demo.dylib
clang caller.c ./libbool_demo.dylib -o caller
./caller

本轮实际执行了这些步骤，C调用的256个值通过。动态库和调用程序放在同一验证目录，并从该目录运行。这只是本机普通ABI往返检查；架构与工具链都不同于公告目标，不能把通过写成“证明x86_64回归已修复”。

怎样才算修复回归测试

需要去官方链接的复现条件里查受影响工具链、目标ABI及优化选项，在对应平台保留最小失败输入，比较受影响版与修复版。还应检查测试是否真的观察到ABI要求的位，而不只是经过调用端转换后的布尔结果。本篇的简单C断言可能不足以捕捉公告的具体高位问题。

Nomicon FFI章节可以帮助补接口契约，但也不能替代目标平台实验。这份学习笔记留下的是一个能继续扩展的边界测试，没有把一条公告包装成我亲历的线上事故。