Chapter 33C Interop Import Export Abi

C互操作

概述

前一章的HTTP客户端消费了用Zig编写的数据(32);现实系统通常必须依赖多年的C代码。本章展示Zig 0.15.2如何将C视为一等公民:我们使用@cImport引入头文件,将Zig函数导出回C,并验证记录保持其ABI承诺。c.zig

标准库现在通过影响I/O栈的相同现代化将std.cstd.builtin.CallingConvention路由,因此本章重点介绍最相关的变化,同时保持示例仅通过zig run即可运行。builtin.zigv0.15.2

C互操作架构

在深入@cImport机制之前,了解Zig的C互操作层如何组织很有价值。以下图表显示了从用户代码到libc和系统调用的完整架构:

graph TB subgraph "User Code Layer" USER["User Application Code"] end subgraph "Standard Library Abstractions" OS["std.os<br/>OS-specific wrappers"] POSIX["std.posix<br/>POSIX API layer"] FS["std.fs<br/>Filesystem API"] NET["std.net<br/>Networking API"] PROCESS["std.process<br/>Process management"] end subgraph "C Interoperability Layer" C["std.c<br/>Main C types module"] subgraph "Platform-Specific Modules" DARWIN["c/darwin.zig<br/>macOS/iOS types"] FREEBSD["c/freebsd.zig<br/>FreeBSD types"] LINUX["os/linux.zig<br/>Linux syscalls"] WINDOWS["os/windows.zig<br/>Windows API"] NETBSD["c/netbsd.zig<br/>NetBSD types"] OPENBSD["c/openbsd.zig<br/>OpenBSD types"] SOLARIS["c/solaris.zig<br/>Solaris types"] HAIKU["c/haiku.zig<br/>Haiku types"] DRAGONFLY["c/dragonfly.zig<br/>DragonflyBSD types"] end C --> DARWIN C --> FREEBSD C --> LINUX C --> WINDOWS C --> NETBSD C --> OPENBSD C --> SOLARIS C --> HAIKU C --> DRAGONFLY end subgraph "System Layer" LIBC["libc<br/>C Standard Library"] SYSCALL["System Calls<br/>Direct syscall interface"] WINAPI["Windows API<br/>kernel32/ntdll"] end USER --> OS USER --> POSIX USER --> FS USER --> NET USER --> PROCESS OS --> C POSIX --> C FS --> POSIX NET --> POSIX PROCESS --> POSIX DARWIN --> LIBC FREEBSD --> LIBC NETBSD --> LIBC OPENBSD --> LIBC SOLARIS --> LIBC HAIKU --> LIBC DRAGONFLY --> LIBC LINUX --> LIBC LINUX --> SYSCALL WINDOWS --> WINAPI

这种架构揭示了std.c不是单一模块——它是一个使用编译时逻辑(builtin.os.tag)导入特定平台C类型定义的分发器。当为macOS编写Zig代码时,std.cc/darwin.zig提取类型;在FreeBSD上,它使用c/freebsd.zig;在Windows上,使用os/windows.zig;依此类推。这些特定于平台的模块定义C类型,如c_inttimespecfd_t和平台常量,然后与libc(当指定-lc时)或直接系统调用(在Linux上)接口。重要的是,Zig自己的标准库(std.fsstd.netstd.process)使用相同的C互操作层——当你调用std.posix.open()时,它在内部解析为std.c.open()。理解这种架构有助于你推理为什么某些C类型在某些平台上可用而在其他平台上不可用,为什么需要-lc来链接libc符号,以及你的@cImport代码如何与Zig内置的C互操作并置。

学习目标

  • 使用@cImport和内置C工具链将Zig可执行文件连接到C头文件和配套源码。
  • 使用C ABI导出Zig函数,以便现有C代码可以在不依赖粘合代码的情况下调用它们。
  • 将C结构映射到Zig extern结构并确认布局、大小和调用语义对齐。

将C API导入Zig

@cImport与你的Zig模块一起编译一段C代码,尊重你通过命令行传递的包含路径、定义和额外C源。这使得一个可执行文件可以在不需要单独构建系统的情况下同时依赖两种语言。

通过往返

第一个示例提取一个头文件和将两个整数相乘的C源,然后演示从同一头文件中的内联C调用Zig导出的函数。

Zig
// Import the Zig standard library for basic functionality
const std = @import("std");

// Import C header file using @cImport to interoperate with C code
// This creates a namespace 'c' containing all declarations from "bridge.h"
const c = @cImport({
    @cInclude("bridge.h");
});

// Export a Zig function with C calling convention so it can be called from C
// The 'export' keyword makes this function visible to C code
// callconv(.c) ensures it uses the platform's C ABI for parameter passing and stack management
export fn zig_add(a: c_int, b: c_int) callconv(.c) c_int {
    return a + b;
}

pub fn main() !void {
    // Create a fixed-size buffer for stdout to avoid heap allocations
    var stdout_buffer: [128]u8 = undefined;
    var stdout_writer = std.fs.File.stdout().writer(&stdout_buffer);
    const out = &stdout_writer.interface;

    // Call C function c_mul from the imported header
    // This demonstrates Zig calling into C code seamlessly
    const mul = c.c_mul(6, 7);
    
    // Call C function that internally calls back into our exported zig_add function
    // This demonstrates the round-trip: Zig -> C -> Zig
    const sum = c.call_zig_add(19, 23);

    // Print the result from the C multiplication function
    try out.print("c_mul(6, 7) = {d}\n", .{mul});
    
    // Print the result from the C function that called our Zig function
    try out.print("call_zig_add(19, 23) = {d}\n", .{sum});
    
    // Flush the buffered output to ensure all data is written
    try out.flush();
}

此程序通过@cInclude包含bridge.h,链接配套的bridge.c,并以平台的C调用约定导出zig_add,以便内联C可以回调到Zig。

运行
Shell
$ zig run \
    -Ichapters-data/code/33__c-interop-import-export-abi \
    chapters-data/code/33__c-interop-import-export-abi/01_c_roundtrip.zig \
    chapters-data/code/33__c-interop-import-export-abi/bridge.c
输出
Shell
c_mul(6, 7) = 42
call_zig_add(19, 23) = 42

传递-I保持头文件可发现,在同一命令行上列出C文件指示Zig编译器编译并将其链接到运行工件中。build.zig

向C导出Zig函数

当你标记export并选择callconv(.c)时,Zig函数获得C ABI,这扩展到目标的默认C调用约定。任何可以通过@cImport从内联C调用的函数也可以从具有相同原型单独编译的C对象调用,因此当你发布共享库时,此模式同样有效。

理解C调用约定

callconv(.c)注释不是单一通用调用约定——它基于目标架构解析为特定于平台的约定。以下图表显示此解析如何工作:

graph LR subgraph "C Calling Convention Resolution" TARGET["target.cCallingConvention()"] TARGET --> X86["x86_64: SysV or Win64"] TARGET --> ARM["aarch64: AAPCS"] TARGET --> WASM["wasm32/64: C"] TARGET --> RISCV["riscv64: C"] TARGET --> SPIRV["spirv: unsupported"] end subgraph "Platform Specifics" X86 --> SYSV["SysV<br/>Linux, macOS, BSD"] X86 --> WIN64["Win64<br/>Windows"] ARM --> AAPCS["AAPCS<br/>standard ARM ABI"] end

当你编写callconv(.c)时,Zig自动为你的目标选择适当的C调用约定。在x86_64 Linux、macOS或BSD系统上,这解析为System V ABI——参数通过寄存器rdirsirdxrcxr8r9传递,然后通过栈;返回值使用rax。在x86_64 Windows上,它成为Win64调用约定——参数通过rcxrdxr8r9传递,然后通过栈;调用者必须保留阴影空间。在ARM(aarch64)上,它是AAPCS(ARM架构过程调用标准),有自己的寄存器使用规则。这种自动解析就是为什么相同的export fn zig_add(a: i32, b: i32) callconv(.c) i32在未经修改的情况下跨平台正确工作——Zig为每个目标生成正确的前言、尾声和寄存器使用。当调试调用约定不匹配或编写汇编互操作时,知道哪个约定处于活动状态有助于你正确匹配寄存器分配和栈布局。

匹配数据布局和ABI保证

可调用只是工作的一半;你还需要就布局规则达成一致,以便结构和聚合在边界两侧具有相同的大小、对齐和字段排序。

理解ABI和对象格式

应用二进制接口(ABI)定义调用约定、名称修饰、结构布局规则以及类型如何在函数之间传递。不同的ABI有不同的规则,这会影响C互操作兼容性:

graph TB subgraph "Common ABIs" ABI["Abi enum"] ABI --> GNU["gnu<br/>GNU toolchain"] ABI --> MUSL["musl<br/>musl libc"] ABI --> MSVC["msvc<br/>Microsoft Visual C++"] ABI --> NONE["none<br/>freestanding"] ABI --> ANDROID["android, gnueabi, etc<br/>platform variants"] end subgraph "Object Formats" OFMT["ObjectFormat enum"] OFMT --> ELF["elf<br/>Linux, BSD"] OFMT --> MACHO["macho<br/>Darwin systems"] OFMT --> COFF["coff<br/>Windows PE"] OFMT --> WASM["wasm<br/>WebAssembly"] OFMT --> C["c<br/>C source output"] OFMT --> SPIRV["spirv<br/>Shaders"] end

ABI选择影响extern struct字段的布局方式。gnu ABI(GNU工具链,用于大多数Linux系统)遵循来自GCC的特定结构填充和对齐规则。msvc ABI(Microsoft Visual C++)有不同的规则——例如,long在Windows x64上是32位,但在Linux x64上是64位。musl ABI以与glibc略有不同的调用约定定位musl libc。none ABI用于没有libc的独立环境。当你声明extern struct SensorData时,Zig使用目标的ABI规则来计算字段偏移和填充,确保它们与C将产生的内容匹配。对象格式(ELF、Mach-O、COFF、WASM)确定使用哪个链接器以及如何编码符号,但ABI确定实际内存布局。这就是为什么章节强调@sizeOf检查——如果Zig和C在结构大小上不一致,你可能有ABI不匹配或错误的目标规范。

用于共享布局

此示例镜像传感器固件发布的C结构。我们导入头文件,声明具有匹配字段的extern struct,并双重检查Zig和C在调用从C编译的辅助例程之前就大小达成一致。

Zig

// Import the Zig standard library for basic functionality
const std = @import("std");

// Import C header file using @cImport to interoperate with C code
// This creates a namespace 'c' containing all declarations from "abi.h"
const c = @cImport({
    @cInclude("abi.h");
});

// Define a Zig struct with 'extern' keyword to match C ABI layout
// The 'extern' keyword ensures the struct uses C-compatible memory layout
// without Zig's automatic padding optimizations
const SensorSample = extern struct {
    temperature_c: f32,  // Temperature reading in Celsius (32-bit float)
    status_bits: u16,    // Status flags packed into 16 bits
    port_id: u8,         // Port identifier (8-bit unsigned)
    reserved: u8 = 0,    // Reserved byte for alignment/future use, default to 0
};

// Convert a C struct to its Zig equivalent using pointer casting
// This demonstrates type-punning between C and Zig representations
// @ptrCast reinterprets the memory layout without copying data
fn fromC(sample: c.struct_SensorSample) SensorSample {
    return @as(*const SensorSample, @ptrCast(&sample)).*;
}

pub fn main() !void {
    // Create a fixed-size buffer for stdout to avoid allocations
    var stdout_buffer: [256]u8 = undefined;
    var stdout_writer = std.fs.File.stdout().writer(&stdout_buffer);
    const out = &stdout_writer.interface;

    // Print size comparison between C and Zig struct representations
    // Both should be identical due to 'extern' struct attribute
    try out.print("sizeof(C struct) = {d}\n", .{@sizeOf(c.struct_SensorSample)});
    try out.print("sizeof(Zig extern struct) = {d}\n", .{@sizeOf(SensorSample)});

    // Call C functions to create sensor samples with specific values
    const left = c.make_sensor_sample(42.5, 0x0102, 7);
    const right = c.make_sensor_sample(38.0, 0x0004, 9);
    
    // Call C function that operates on C structs and returns a computed value
    const total = c.combined_voltage(left, right);

    // Convert C structs to Zig structs for idiomatic Zig access
    const zig_left = fromC(left);
    const zig_right = fromC(right);

    // Print sensor data from the left port with formatted output
    try out.print(
        "left port {d}: {d} status bits, {d:.2} °C\n",
        .{ zig_left.port_id, zig_left.status_bits, zig_left.temperature_c },
    );
    
    // Print sensor data from the right port with formatted output
    try out.print(
        "right port {d}: {d} status bits, {d:.2} °C\n",
        .{ zig_right.port_id, zig_right.status_bits, zig_right.temperature_c },
    );
    
    // Print the combined voltage result computed by C function
    try out.print("combined_voltage = {d:.3}\n", .{total});
    
    // Flush the buffered output to ensure all data is written
    try out.flush();
}

辅助函数源自abi.c,因此运行命令链接两个文件并将C聚合例程暴露给Zig。

运行
Shell
$ zig run \
    -Ichapters-data/code/33__c-interop-import-export-abi \
    chapters-data/code/33__c-interop-import-export-abi/02_abi_layout.zig \
    chapters-data/code/33__c-interop-import-export-abi/abi.c
输出
Shell
sizeof(C struct) = 8
sizeof(Zig extern struct) = 8
left port 7: 258 status bits, 42.50 °C
right port 9: 4 status bits, 38.00 °C
combined_voltage = 1.067

如果@sizeOf断言不一致,请双重检查填充字节,优先选择extern struct而不是packed,除非你有明确理由改变ABI规则。

translate-c和构建集成

对于更大的头文件,考虑运行zig translate-c将它们快照为Zig源。构建系统也可以通过addCSourceFileaddIncludeDir注册C对象和头文件,使上面的zig run调用成为可重复包的一部分,而不是临时命令。

注意事项与限制

  • Zig不自动链接平台库;在导入项目之外的API时传递-lc或添加适当的构建选项。
  • @cImport发出一个翻译单元;用#pragma once或包含守护包装头文件以避免重复定义,就像在纯C项目中一样。
  • 除非你控制编译器和目标,否则避免packed;压缩字段可以改变对齐保证,并在禁止的架构上导致未对齐加载。

练习

  • 用返回按值传递结构的函数扩展bridge.h,并演示从Zig消费它而不通过指针复制。
  • 导出一个填充调用者提供的C缓冲区的Zig函数,并使用zig build-obj加上llvm-nm或你平台的等效工具检查其符号。
  • 在ABI示例中将extern struct交换为packed struct,并在具有严格对齐的目标上运行它以观察发出的机器代码的差异。

限制、替代方案和边缘案例

  • 某些C ABI修饰名称(例如Windows __stdcall);在与非默认ABI互操作时,覆盖调用约定或使用带有显式符号名称的@export
  • @cImport不能编译C——使用`extern "C"`包装器转换头文件或在绑定C库时使用C垫片。
  • 桥接可变参数函数时,优先编写显式封送参数的Zig包装器;Zig的可变参数仅涵盖C的默认提升,不包括自定义省略号语义。

Help make this chapter better.

Found a typo, rough edge, or missing explanation? Open an issue or propose a small improvement on GitHub.