C语言支持错误中断的函数顺序执行：如何兼容不同入参的函数？

下面是两种无未定义行为、可直接落地的实现方案，完全不需要用到不安全的指针强制转换。

方案1：宏封装实现（代码改动最小） #

直接定义一个通用的执行校验宏，替换重复的if判断逻辑，不需要修改原有函数，也不需要处理参数兼容问题：

// 定义通用执行宏，出错直接触发错误处理并跳出
#define RUN_AND_CHECK(err, func_expr) \
    do { \
        err = func_expr; \
        if (err != 0) { \
            handle_error(err); \
            break; \
        } \
    } while(0)

使用时代码非常简洁，没有冗余逻辑：

while (1) {
    int error = 0;
    RUN_AND_CHECK(error, function_1());
    RUN_AND_CHECK(error, function_2(some_parameter));
    RUN_AND_CHECK(error, function_3());
    // 剩余函数依次添加即可，即使15个调用也非常清晰
}

这个方案的优势是不需要额外的包装代码，参数怎么传都直接写在宏调用里，可读性最高，调试也方便。

方案2：统一签名函数指针数组（适合函数数量多、需要动态增减的场景） #

如果你的函数列表需要动态修改，不想在循环里写死每一行调用，可以把每个函数包装成统一签名的函数，解决参数不一致的问题：

固定参数场景 #

如果参数是提前确定的常量/全局变量，直接写无参包装函数：

// 统一函数签名
typedef int (*task_func_t)(void);

// 给带参函数写包装
static int wrap_function2(void) {
    return function2(some_parameter);
}

// 函数数组统一存包装后的函数
const task_func_t tasks[] = {
    function_1,
    wrap_function2,
    function_3,
    // 其他函数/包装函数依次添加
};
const int task_cnt = sizeof(tasks) / sizeof(tasks[0]);

执行逻辑：

while (1) {
    int error = 0;
    for (int i = 0; i < task_cnt; i++) {
        error = tasks[i]();
        if (error != 0) {
            handle_error(error);
            break;
        }
    }
}

动态参数场景 #

如果参数是动态生成的，可以加一个统一的上下文结构体传递参数：

// 上下文结构体，存储所有函数需要的动态参数
typedef struct {
    int func2_param;
    // 其他函数需要的参数依次添加
} TaskContext;

// 统一签名改为带上下文指针
typedef int (*task_func_t)(TaskContext* ctx);

static int wrap_function2(TaskContext* ctx) {
    return function2(ctx->func2_param);
}

static int wrap_function1(TaskContext* ctx) {
    (void)ctx; // 不需要参数直接忽略即可
    return function1();
}

执行时传入上下文即可：

while (1) {
    TaskContext ctx;
    // 每次循环提前初始化好上下文中的所有参数
    ctx.func2_param = some_parameter;
    
    int error = 0;
    for (int i = 0; i < task_cnt; i++) {
        error = tasks[i](&ctx);
        if (error != 0) {
            handle_error(error);
            break;
        }
    }
}

为什么不要用「脏转换」 #

不同参数列表的函数指针互相转换再调用属于C标准明确的未定义行为，会有栈不平衡、参数解析错误、调用约定不匹配等隐性问题，不同架构、不同编译器优化等级下表现可能完全不一致，出了问题极难排查，完全没必要为了少写几行代码冒这个风险。

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