C语言中派生结构体函数指针转基类型是否为未定义行为？

背景回顾：经典的结构体继承式多态 #

我们在C里模拟面向对象多态时，常用这种经典的结构体嵌套+虚表模式：

struct parent;
struct vtable { void(*op)(struct parent *obj); };
struct parent { struct vtable *vtable; };
struct child { struct parent parent; int bar; };

常规实现里，子类虚函数必须先把父类指针向下转换为子类指针才能访问子类成员：

void child_op(struct parent *obj) {
    struct child *child = (struct child *)obj;
    /* 执行子类逻辑 */
}
static struct vtable child_vtable = { .op = child_op, };

动态分派时直接通过父类指针调用虚表函数：

void foo(struct parent *obj) { obj->vtable->op(obj); }

但如果明确知道对象是子类类型（比如刚分配完成时），直接调用子类函数还得先把子类指针转成父类指针，略显繁琐：

void bar(void) {
    struct child *obj = malloc(sizeof(*obj));
    obj->parent.vtable = &child_vtable;
    child_op(&obj->parent);
}

核心问题：直接转换函数指针类型是否合法？ #

现在有人提出一种简化方案：把子类虚函数的参数直接设为子类指针，仅在赋值给虚表时做一次函数指针类型转换，代码如下：

void child_op(struct child *obj) {
    // 省去函数内部的向下转换
    /* 执行子类逻辑 */
}
// 关键操作：将child_op指针转换为父类虚函数类型
static struct vtable child_vtable = { .op = (void (*)(struct parent *))child_op, };
void foo(struct child *obj) {
    // 直接调用，无需转换指针
    child_op(obj);
}

这种做法是否合法？会不会触发C标准中的未定义行为？

合法性分析：从C标准角度出发 #

要解答这个问题，核心是判断void (*)(struct parent *)和void (*)(struct child *)两种函数指针类型的兼容性，以及转换后调用的行为是否符合标准：

• C标准允许不同类型的函数指针之间强制转换，但默认规则是只有转换回原类型后调用才是定义良好的。
• 但我们的场景有特殊前提：struct child的第一个成员是struct parent，这意味着struct child*和struct parent*的指针表示是兼容的——子类指针转换为父类指针时，值不变，指向父类子对象的起始地址（也就是整个子类对象的起始地址）。

当我们把child_op（参数为struct child*）转换成void (*)(struct parent*)并调用时，实际传入的struct parent*本质上指向子类对象的起始地址，和struct child*指向的内存地址完全一致。这种情况下，在大多数主流编译器（GCC、Clang、MSVC等）上，代码可以正常运行。

但严格来说，这确实属于未定义行为——C标准并没有明确允许这种跨类型的函数指针调用，编译器可以基于"函数参数类型严格匹配"的假设做激进优化，极端场景下可能出现异常。

可能触发问题的场景 #

虽然常规平台下风险极低，但以下场景可能导致意外：

• 非标准结构体布局：如果编译器通过特殊编译选项调整了结构体成员布局，导致struct parent不是struct child的第一个成员，或者存在额外填充，指针转换会直接出错。不过只要遵循经典继承模式，这种情况几乎不会发生。
• 极端优化等级：部分编译器在最高优化等级下，会基于函数参数类型做针对性优化。比如假设传入child_op的一定是struct child*，若实际传入的是struct parent*（哪怕地址相同），可能导致优化后的代码行为异常。
• 调用约定差异：如果两种函数指针类型对应的调用约定不同（比如特殊平台的参数传递方式），会导致调用出错。但此场景下两个函数都是void返回值+单个指针参数，调用约定通常一致，风险极低。

有没有知名项目使用该方案？ #

是的，不少知名C项目都采用了类似的简化方案：

• Linux内核：在设备模型、文件系统等面向对象风格的子系统中，会用类似的函数指针转换减少冗余类型转换，不过内核有自己的编译规则和平台限制，对标准兼容性的要求和用户态程序不同。
• GLib的GObject系统：作为C语言模拟面向对象的经典实现，GObject的虚表机制中也存在类似的函数指针类型转换，用于简化子类方法的实现。

总结 #

• 工程实践角度：在主流编译器（GCC、Clang、MSVC）和常见平台（x86、ARM等）上，只要保证父类是子类的第一个成员，这种做法完全可行，还能减少代码中的冗余转换。
• C标准角度：属于未定义行为，因为标准未明确允许这种跨类型函数指针调用。
• 风险可控性：只要遵循经典结构体继承布局，不使用极端编译选项，风险几乎可以忽略。

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