企业官网建设流程全解析

1. 项目概述：为什么可变参数函数在VectorCAST里是个“硬骨头”

VectorCAST是嵌入式C/C++领域里最老牌、也最被航空、医疗、汽车电子这类高可靠场景信任的自动化测试工具。它不是那种写个Hello World就能跑起来的玩具，而是真正要和你的编译器链、目标板、静态分析规则、MISRA合规性检查深度咬合的工业级平台。所以当标题问“如何在VectorCAST中测试可变参数函数”，这问题背后其实藏着三层现实压力：第一层是语法层面——printf、sprintf、vsnprintf这类函数用...声明，编译器生成的调用约定和栈帧布局和普通函数完全不同；第二层是工具链层面——VectorCAST的静态代码分析器（VectorCAST/C++）在解析AST时，对va_list类型、va_start/va_arg宏的语义理解是有限的，它更习惯处理确定参数个数和类型的签名；第三层是工程实践层面——你在AUTOSAR项目里写的日志封装函数，在航电系统里写的诊断上报接口，往往都依赖可变参数来实现灵活的消息格式化，但一旦这些函数进了VectorCAST的测试套件，轻则覆盖率统计失真，重则测试用例根本无法生成，甚至导致整个测试框架报错退出。

我做过三个车规级ECU项目的VectorCAST落地，其中两个项目的核心诊断模块就卡在这个点上。第一次是在某德系Tier1的网关控制器上，他们用自定义的LOG_DEBUG(fmt, ...)封装了所有调试输出，结果VectorCAST跑完静态分析后，直接把整个log.c标为“不可测试文件”，覆盖率报告里这一块永远是0%。后来查日志才发现，VectorCAST的解析器在遇到va_start(ap, fmt)时，误判为ap变量未初始化，触发了MISRA Rule 9.1的告警，进而阻断了后续的测试桩（stub）生成流程。第二次是在一个国产飞行控制软件里，他们用vsnprintf做状态字符串拼接，VectorCAST虽然能生成测试用例，但所有传入...部分的参数都被默认置为0，导致实际运行时vsnprintf返回-1，缓冲区溢出，测试直接崩溃。这说明，VectorCAST不是“不能测”，而是默认行为完全没考虑可变参数的动态性——它把...当成一个黑盒，而不是一组需要被显式控制、赋值、验证的独立输入。

所以这篇文章不讲“能不能测”，而是直奔“怎么稳、准、狠地测”。核心思路就一条：绕过VectorCAST对...语法的原生解析缺陷，用User Code机制把可变参数“固化”成确定结构，再用VectorCAST的标准测试流程去覆盖它。这个方案不需要改你原有的函数签名，不破坏已有代码风格，也不引入额外的第三方库，纯粹靠VectorCAST自身提供的扩展能力完成。适合所有正在用VectorCAST做DO-178B/C、ISO 26262或IEC 62304合规性验证的团队，尤其适合那些已经写了大量可变参数日志、诊断、配置加载函数，但又被测试覆盖率卡住脖子的工程师。

2. 整体设计思路与方案选型逻辑

2.1 为什么不用“直接测试”？——VectorCAST的底层限制

很多人第一反应是：“既然函数原型里写了...，那VectorCAST生成测试用例时，难道不能自动填几个参数进去？” 理论上可以，但实操中几乎必然失败。原因在于VectorCAST的测试用例生成引擎（Test Case Generator）工作在AST（抽象语法树）层面，而C标准里对可变参数函数的定义是“编译器特定”的。比如GCC用__builtin_va_start，ARMCC用__va_start，IAR用__va_start加特殊寄存器映射。VectorCAST为了跨编译器兼容，选择了一种保守策略：它只识别函数声明中的显式参数列表，对...部分不做任何AST节点展开，而是标记为VARARG_PLACEHOLDER。这意味着：

• 在生成测试桩（Stub）时，VectorCAST不会为...部分生成任何参数绑定逻辑；
• 在录制（Record）模式下，它能捕获到调用时的实际参数值，但回放（Playback）时，这些值会被丢弃，因为没有对应的变量名和内存地址映射；
• 在覆盖率统计中，va_start、va_arg、va_end这三个宏内部的汇编指令（如mov r0, sp）无法被Instrumentation插桩，导致这部分代码永远显示为“未执行”。

我试过强行让VectorCAST生成带...的测试用例，结果是生成的.tst文件里，...部分被写成/* VARARG: not supported */，然后测试执行时报Error: Invalid argument count for function 'my_printf'。这说明VectorCAST官方也承认这是个已知限制，解决方案不在核心引擎里，而在User Code扩展机制中。

2.2 User Code是唯一可行路径——它的三个不可替代优势

VectorCAST的User Code功能，本质是让你在测试框架的“夹层”里插入自己的C代码，它在测试用例执行前、后、以及桩函数内部都能被调用。针对可变参数函数，我们利用的是桩函数内部（Stub Function Body）这个钩子。它的优势有三点：

第一，完全绕过AST解析。我们不指望VectorCAST去理解...，而是自己写一个确定参数个数的“壳函数”，比如my_printf_stub(int arg_count, const char* fmt, ...)，然后在User Code里把这个壳函数的...部分手动展开成数组，再调用真正的my_printf。VectorCAST只看到arg_count和fmt这两个确定参数，解析毫无压力。

第二，参数可控、可验证。在壳函数里，我们可以用va_list安全地遍历所有可变参数，并把它们存进一个全局数组（如g_varargs_buffer[16]）。这样，测试用例里就可以直接给这个数组赋值，比如g_varargs_buffer[0] = 123; g_varargs_buffer[1] = (int)"hello";，VectorCAST能100%跟踪这些变量的读写，覆盖率精准到字节。

第三，行为可拦截、可断言。真正的my_printf可能往串口发数据，或者写进环形缓冲区。我们在User Code的桩函数里，可以先不调用原函数，而是把fmt和展开后的参数全部存进一个结构体，比如struct captured_call { char fmt[256]; int args[16]; int arg_count; }，然后在测试用例里用ASSERT_EQ去比对这个结构体的内容。这就把“不可测的副作用”转化成了“可断言的数据状态”。

这个方案不是权宜之计，而是VectorCAST官方文档里明确推荐的模式。在《VectorCAST/C++ User Guide》第7章“Advanced Stubbing Techniques”里，专门有一节叫“Handling Variadic Functions”，给出的示例就是用User Code +va_list展开。只不过官方示例只给了骨架，没讲具体怎么和测试用例联动、怎么处理不同参数类型、怎么避免栈溢出——这些才是工程落地的关键坑点，后面会逐个拆解。

2.3 方案对比：为什么不用宏替换或预处理器？

有人会想：“干脆在编译前用宏把my_printf(a,b,c)替换成my_printf_fixed(a,b,c,3)，不就变成固定参数了？” 这个思路看似简单，但会引发三个致命问题：

• 破坏源码可读性和调试体验。你源码里写的是my_printf("val=%d, str=%s", x, y)，但预处理器把它变成my_printf_fixed("val=%d, str=%s", x, y, 2)，调试时GDB看到的函数名和参数全是错的，堆栈追踪完全失效。
• 无法处理运行时参数个数变化。比如my_printf("a=%d", a)和my_printf("a=%d, b=%d, c=%d", a, b, c)混用，宏必须为每种参数个数写一个版本，代码爆炸式增长，维护成本远超收益。
• 与VectorCAST的Instrumentation冲突。VectorCAST的代码插桩（Instrumentation）是在预处理之后、编译之前做的。如果你用宏替换，插桩器看到的已经是my_printf_fixed，但它并不知道这个函数和原始my_printf的语义等价，覆盖率统计会分裂成两个独立函数，失去统一视图。

User Code方案则完全规避了这些问题：源码保持原样，VectorCAST只对原始函数名做插桩，所有“转换”逻辑都在测试框架内部完成，对开发、调试、合规性审查全程透明。

3. 核心细节解析与实操要点

3.1 User Code桩函数的编写规范——类型安全是第一道防线

User Code桩函数不是随便写个C函数就行，它必须严格遵循VectorCAST的ABI（应用二进制接口）约定，否则会导致栈损坏、参数错位、甚至整个测试进程崩溃。关键点有三个：

第一，函数签名必须匹配原始函数的调用约定。假设你的原始函数是int my_log(const char* level, const char* fmt, ...)，那么User Code桩函数的签名必须是：

int my_log_stub(const char* level, const char* fmt, ...);

注意：...必须保留，不能写成void*或其他占位符。VectorCAST在链接时，会把所有对my_log的调用重定向到my_log_stub，如果签名不一致，链接器会报undefined reference，或者更糟——静默地把参数压错栈位置。

第二，va_list操作必须成对且顺序正确。这是踩过最多坑的地方。正确的模板是：

#include <stdarg.h> int my_log_stub(const char* level, const char* fmt, ...) { va_list ap; va_start(ap, fmt); // 必须以最后一个确定参数为基准 // ... 处理可变参数 va_end(ap); // 必须在return前调用 return 0; // 返回值需与原函数一致 }

常见错误：

• va_start(ap, level)：基准参数错了，level不是最后一个确定参数，fmt才是，会导致ap指向错误内存。
• 忘记va_end(ap)：某些编译器（如IAR）会因此产生未定义行为，测试随机失败。
• 在va_arg(ap, int)之后，又调用va_arg(ap, char*)：va_arg是按顺序读取的，类型必须和实际传入一致，否则读到垃圾值。

第三，参数类型推导必须基于fmt字符串。可变参数函数的参数类型，几乎都隐含在fmt里。比如my_log("INFO", "x=%d, y=%s", 123, "abc")，%d对应int，%s对应char*。所以User Code里不能盲目地把所有参数都当int处理。我的做法是：先用一个辅助函数解析fmt，提取所有格式符，存进一个enum arg_type { ARG_INT, ARG_STR, ARG_PTR } type_list[16]数组，然后按顺序调用va_arg(ap, int)或va_arg(ap, char*)。VectorCAST本身不提供fmt解析库，所以这个解析逻辑必须自己写，但很轻量——一个while(*fmt)循环，找%字符，跳过%*、%10s等修饰符，只认%d、%s、%x、%p这几个核心格式符。

3.2 全局缓冲区的设计——大小、对齐与生命周期管理

User Code需要把展开的参数存进一个全局缓冲区，供测试用例读取和断言。这个缓冲区的设计直接影响稳定性和可扩展性。

大小选择：16个参数是黄金平衡点。太小（如4个）不够用，printf("a=%d, b=%d, c=%d, d=%d, e=%d, f=%d", a,b,c,d,e,f)就溢出了；太大（如64个）浪费内存，而且VectorCAST的测试用例变量表有上限。我实测下来，16个是绝大多数嵌入式项目的上限。定义方式：

#define MAX_VARARGS 16 typedef union { int i; char* s; void* p; } vararg_t; static vararg_t g_varargs_buffer[MAX_VARARGS]; static int g_varargs_count = 0;

用union是为了节省空间，同时支持int、char*、void*三种最常用类型。g_varargs_count记录本次调用实际参数个数，避免测试用例读取未初始化的垃圾值。

对齐要求：必须按最大成员对齐。union里void*通常是4字节（ARM Cortex-M）或8字节（x64），所以整个vararg_t必须按8字节对齐。在VectorCAST的User Code里，直接用#pragma pack(8)或__attribute__((aligned(8)))声明全局变量。否则，在某些MCU上，g_varargs_buffer[0].p可能被编译器优化到非对齐地址，导致硬件异常。

生命周期管理：每次调用前清零。这是新手最容易忽略的点。User Code的全局变量在整个测试会话（Test Session）里是持久的，如果不主动清零，上次测试的参数会残留，导致本次测试断言失败。所以my_log_stub开头必须加：

for (int i = 0; i < MAX_VARARGS; i++) { g_varargs_buffer[i].i = 0; } g_varargs_count = 0;

注意：不能用memset(g_varargs_buffer, 0, sizeof(g_varargs_buffer))，因为union里char*和void*的零值是NULL，但int的零值是0，memset是安全的，但显式循环更清晰，也方便加调试打印。

3.3 测试用例与User Code的联动机制——让VectorCAST“看见”参数

VectorCAST的测试用例（.tst文件）本质是一个结构化的文本，它描述了“调用什么函数、传什么参数、期望什么返回值”。要让测试用例能设置g_varargs_buffer，必须通过VectorCAST的外部变量（External Variable）机制。

操作步骤：

1. 在VectorCAST GUI里，打开Project Settings > Test Environment > External Variables；
2. 点击Add，输入变量名g_varargs_buffer，类型选Array of vararg_t，大小填16；
3. 同样添加g_varargs_count，类型int。

这样，VectorCAST就知道这两个变量是“外部可见的”，会在生成的测试驱动代码里自动包含它们的声明和地址引用。然后，在测试用例编辑器里，你可以像设置普通变量一样给它们赋值：

g_varargs_count = 2; g_varargs_buffer[0].i = 42; g_varargs_buffer[1].s = "test";

VectorCAST会把这些赋值语句编译进测试驱动，确保在my_log_stub执行前，缓冲区已经被正确填充。

这里有个关键技巧：不要在测试用例里直接调用my_log，而是调用一个空壳函数（如trigger_my_log），让它内部调用my_log。为什么？因为VectorCAST的测试用例录制（Record）模式，只能捕获“被测试函数”的调用，而my_log是被桩函数拦截的，录制不到它的参数。所以标准流程是：

• 写一个void trigger_my_log(void) { my_log("DEBUG", "val=%d", 123); }
• 在VectorCAST里录制trigger_my_log，它会生成调用my_log的代码；
• 然后手动把生成的.tst文件里的my_log(...)替换成对g_varargs_buffer的赋值，再加一行trigger_my_log()调用。

这个“录制+手动修改”的组合，是我发现的最高效、最不易出错的方式，比纯手写.tst文件靠谱得多。

4. 实操过程与核心环节实现

4.1 完整User Code桩函数示例——带错误处理和日志

下面是一个经过生产环境验证的my_log桩函数完整代码，它包含了所有前述要点，并增加了健壮性检查：

#include <stdarg.h> #include <string.h> #include "vectorcast.h" // VectorCAST提供的头文件，含ASSERT宏 #define MAX_VARARGS 16 #define MAX_FMT_LEN 256 typedef enum { ARG_INT, ARG_STR, ARG_PTR, ARG_UNKNOWN } arg_type_t; typedef union { int i; char* s; void* p; } vararg_t; // 全局缓冲区，VectorCAST可访问 vararg_t g_varargs_buffer[MAX_VARARGS] __attribute__((aligned(8))); int g_varargs_count = 0; char g_last_fmt[MAX_FMT_LEN]; // 辅助函数：解析fmt字符串，返回参数类型数组 static void parse_fmt(const char* fmt, arg_type_t* types, int* count) { *count = 0; const char* p = fmt; while (*p && *count < MAX_VARARGS) { if (*p == '%') { p++; // 跳过% if (*p == '%') { p++; // 转义%% continue; } // 跳过宽度、精度等修饰符，直到找到类型字符 while (*p && !strchr("diouxXfFeEgGaAcCsSpn%", *p)) { p++; } switch (*p) { case 'd': case 'i': case 'o': case 'u': case 'x': case 'X': types[(*count)++] = ARG_INT; break; case 's': types[(*count)++] = ARG_STR; break; case 'p': case 'c': case 'f': case 'e': case 'E': case 'g': case 'G': case 'a': case 'A': types[(*count)++] = ARG_PTR; // 简化处理，指针类统一用PTR break; default: types[(*count)++] = ARG_UNKNOWN; break; } } p++; } } // 主桩函数 int my_log_stub(const char* level, const char* fmt, ...) { // 1. 清零缓冲区 for (int i = 0; i < MAX_VARARGS; i++) { g_varargs_buffer[i].i = 0; } g_varargs_count = 0; strncpy(g_last_fmt, fmt, MAX_FMT_LEN - 1); g_last_fmt[MAX_FMT_LEN - 1] = '\0'; // 2. 解析fmt，获取预期参数个数和类型 arg_type_t expected_types[MAX_VARARGS]; int expected_count = 0; parse_fmt(fmt, expected_types, &expected_count); // 3. 展开可变参数 va_list ap; va_start(ap, fmt); for (int i = 0; i < expected_count && i < MAX_VARARGS; i++) { switch (expected_types[i]) { case ARG_INT: g_varargs_buffer[i].i = va_arg(ap, int); break; case ARG_STR: g_varargs_buffer[i].s = va_arg(ap, char*); break; case ARG_PTR: g_varargs_buffer[i].p = va_arg(ap, void*); break; default: g_varargs_buffer[i].i = 0; // 未知类型，置0 break; } } g_varargs_count = expected_count; va_end(ap); // 4. 可选：调用原函数，或仅做记录 // return my_log_real(level, fmt, /* ... */); // 如果需要真实执行，需在此处重构参数 return 0; // 模拟成功返回 }

这个函数的关键实操细节：

• __attribute__((aligned(8)))确保缓冲区8字节对齐，适配所有主流MCU；
• parse_fmt函数只处理核心格式符，忽略%10s、%-5d等修饰符，因为这些不影响参数类型和个数；
• strncpy加\0终止，防止g_last_fmt缓冲区溢出，这是VectorCAST里常见的安全漏洞；
• 所有va_arg调用都受expected_count保护，绝不会越界读取。

4.2 测试用例编写全流程——从录制到断言

假设我们要测试my_log("ERROR", "sensor=%d, status=0x%x", sensor_val, status_code)，以下是完整的VectorCAST操作步骤：

步骤1：准备测试桩

• 在VectorCAST GUI里，右键点击my_log函数，选择Create Stub；
• 在弹出窗口中，勾选Use User Code，并指定上面写的my_log_stub.c文件；
• 确保g_varargs_buffer和g_varargs_count已在External Variables里注册。

步骤2：录制基础调用

• 创建一个新测试用例，命名为test_my_log_error；
• 点击Record按钮，然后在代码里写一个临时调用：

void test_trigger(void) { int sensor_val = 42; int status_code = 0x1234; my_log("ERROR", "sensor=%d, status=0x%x", sensor_val, status_code); }

• 运行录制，VectorCAST会生成一个.tst文件，内容类似：

// Generated by VectorCAST Recorder #include "test_my_log_error.h" void test_my_log_error(void) { test_trigger(); }

步骤3：手动编辑测试用例

• 打开生成的.tst文件，删除test_trigger()调用；
• 插入对全局缓冲区的赋值：

// 设置期望的fmt字符串 strcpy(g_last_fmt, "sensor=%d, status=0x%x"); // 设置参数个数 g_varargs_count = 2; // 设置第一个参数：sensor_val = 42 g_varargs_buffer[0].i = 42; // 设置第二个参数：status_code = 0x1234 g_varargs_buffer[1].i = 0x1234; // 调用触发函数（此时my_log_stub会被执行） test_trigger();

步骤4：添加断言验证

• 在test_trigger()之后，加入断言：

// 验证fmt字符串是否匹配 ASSERT_STR_EQ(g_last_fmt, "sensor=%d, status=0x%x"); // 验证参数个数 ASSERT_EQ(g_varargs_count, 2); // 验证第一个参数值 ASSERT_EQ(g_varargs_buffer[0].i, 42); // 验证第二个参数值 ASSERT_EQ(g_varargs_buffer[1].i, 0x1234);

VectorCAST的ASSERT_*宏会自动在测试报告里生成PASS/FAIL标记，并高亮失败详情。

步骤5：运行并验证

• 点击Run Test，VectorCAST会编译、链接、执行测试；
• 在Test Results窗口里，你会看到test_my_log_error的状态是PASSED，并且Coverage Report里my_log_stub的函数体100%被覆盖，包括va_start、va_arg、va_end所在的行。

这个流程看起来步骤多，但熟练后，一个测试用例5分钟内就能搞定。关键是把“录制”当作起点，而不是终点——录制只是帮你生成调用框架，真正的逻辑控制权在你手动编辑的.tst文件里。

4.3 参数类型混合处理实战——%s和%d共存的案例

可变参数函数最麻烦的不是单一类型，而是混合类型。比如my_log("INFO", "name=%s, id=%d, ptr=%p", name_str, id_num, ptr_addr)。User Code必须能区分char*、int、void*，否则g_varargs_buffer[0].s会被当成int读取，导致断言失败。

实操要点：

• parse_fmt函数必须准确识别%s、%d、%p，并分别返回ARG_STR、ARG_INT、ARG_PTR；
• 在my_log_stub的va_arg循环里，必须根据expected_types[i]选择正确的类型：

switch (expected_types[i]) { case ARG_INT: g_varargs_buffer[i].i = va_arg(ap, int); // 注意：va_arg(int)不是va_arg(int*) break; case ARG_STR: g_varargs_buffer[i].s = va_arg(ap, char*); // char*是地址，直接赋值 break; case ARG_PTR: g_varargs_buffer[i].p = va_arg(ap, void*); // void*是通用地址 break; }

• 测试用例里，对char*类型的赋值必须用字符串字面量或已声明的变量：

char* test_name = "motor1"; g_varargs_buffer[0].s = test_name; // 正确：赋值地址 // g_varargs_buffer[0].s = "motor1"; // 也可以，但要注意字符串常量生命周期

• 对void*类型的赋值，可以用(void*)0x20001000这样的硬编码地址，或者用&some_global_var。

我在一个电机驱动项目里，用这个方法测试了包含%s、%d、%x、%p四种格式符的diag_log函数，一次通过。关键经验是：永远用va_arg(ap, correct_type)，而不是va_arg(ap, int)然后强制转换。因为va_arg的实现依赖于类型大小，int和void*在32位系统上都是4字节，但在64位系统上void*是8字节，强制转换会导致栈偏移错误。

5. 常见问题与排查技巧实录

5.1 典型问题速查表

5.2 我踩过的三个深坑及独家避坑技巧

坑一：va_list在不同编译器下的ABI差异在IAR EWARM环境下，va_start(ap, fmt)后，ap的值是一个指向栈顶的指针，而GCC下它可能是一个结构体。我第一次在IAR项目里用memcpy(&temp_ap, &ap, sizeof(ap))试图保存ap状态，结果测试随机失败。后来查IAR手册才知道，va_list在IAR里是typedef char* __va_list;，直接复制指针没问题，但GCC下是typedef struct { ... } __va_list;，必须用va_copy。避坑技巧：永远用va_copy(dest, src)来保存va_list状态，不要用memcpy。VectorCAST支持va_copy，它是C99标准，所有现代编译器都兼容。

坑二：%s参数的字符串生命周期问题测试用例里写g_varargs_buffer[0].s = "hello";，然后在my_log_stub里用printf("%s", g_varargs_buffer[0].s)，结果打印乱码。原因是字符串常量"hello"存储在.rodata段，而VectorCAST的测试进程可能在不同内存区域运行，地址无效。避坑技巧：所有char*类型的参数，必须指向测试用例里声明的static char数组。例如：

static char test_str[32] = "hello"; g_varargs_buffer[0].s = test_str;

这样test_str在.data段，地址稳定。

坑三：%p格式符的跨平台表示不一致printf("%p", ptr)在ARM Cortex-M上输出0x20001000，在x64 Linux上输出0x7fffb1234567，长度不同。如果测试用例里用ASSERT_STR_EQ比对，会因平台而异。避坑技巧：对%p参数，不要断言完整字符串，而是断言其数值。在my_log_stub里，把void*转成uintptr_t存进g_varargs_buffer[i].i，然后用ASSERT_EQ比对数值：

case ARG_PTR: g_varargs_buffer[i].i = (uintptr_t)va_arg(ap, void*); // 存数值，不是地址 break;

这样，无论平台如何，数值比较都是稳定的。

5.3 性能与资源占用实测数据

在STM32F407（168MHz，192KB RAM）上，用上述方案测试一个含4个参数的my_log调用：

• 内存开销：g_varargs_buffer（16×8=128字节）+g_last_fmt（256字节）= 384字节，对嵌入式系统完全无压力；
• 时间开销：parse_fmt平均耗时8.2μs（用DWT_CYCCNT计数器实测），va_arg循环耗时3.5μs，总开销<12μs，远低于UART日志输出的毫秒级延迟；
• 覆盖率提升：原本my_log函数体覆盖率0%，启用User Code后，函数体、va_start、va_arg、va_end全部100%覆盖，整体模块覆盖率从72%提升到89%。

这个数据来自我们实际交付的医疗设备项目，客户审核时特别关注了这部分资源占用，结论是“完全满足IEC 62304 Class C要求”。

6. 进阶扩展与工程化建议

6.1 自动化脚本：从.h头文件生成User Code模板

手动写my_log_stub.c太慢，尤其当项目里有十几个可变参数函数时。我写了一个Python脚本，能自动解析C头文件，生成User Code桩函数框架：

#!/usr/bin/env python3 import re import sys def parse_header(file_path): with open(file_path, 'r') as f: content = f.read() # 匹配可变参数函数声明：返回类型 函数名(参数列表, ...); pattern = r'(\w+\s+)*(\w+)\s+(\w+)\s*\(([^)]*?)\s*,\s*\.\s*\.\s*\.\s*\)\s*;' matches = re.findall(pattern, content) return matches def generate_stub(func_name, return_type, params): # 简化参数列表，只取最后一个确定参数名 param_list = [p.strip() for p in params.split(',') if p.strip()] last_fixed = param_list[-1].split()[-1] if param_list else 'dummy' stub = f'''#include <stdarg.h> #include "vectorcast.h" #define MAX_VARARGS 16 typedef union {{ int i; char* s; void* p; }} vararg_t; vararg_t g_{func_name}_buffer[MAX_VARARGS] __attribute__((aligned(8))); int g_{func_name}_count = 0; {return_type} {func_name}_stub({params}, ...) {{ for (int i = 0; i < MAX_VARARGS; i++) g_{func_name}_buffer[i].i = 0; g_{func_name}_count = 0; va_list ap; va_start(ap, {last_fixed}); // TODO: 解析fmt，展开参数 va_end(ap); return ({return_type})0; }}''' return