带void*参数的函数指针类型转换：qsort传参警告与风险解析

为什么“给void*补具体指向类型”的写法不被编译器认可 #

很多人遇到这个警告都会觉得有点拧巴：从逻辑上讲，void*是无类型的泛化指针，把它替换成具体指向int的指针，明明是更精准的正向操作，凭什么编译器不认？
本质上是你把两套完全不同的规则搞混了：

• 数据指针层面，C标准确实允许void*和任意对象指针隐式互相转换，这套规则是通用的
• 但函数指针的类型校验是完全刚性的：只要函数签名里有哪怕一个参数的指针类型对不上，两个函数指针就属于完全不同的类型，不会触发任何隐式转换。qsort作为标准库函数，被明确定义为只接收签名为int(*)(const void*, const void*)的回调，你写的comparison函数签名是int(*)(const int*, const int*)，二者类型不兼容，编译器弹出警告是严格按照类型规则做的校验，绝不是多事的过度提示。

这种不匹配的写法到底有没有严重问题 #

你在当前环境下觉得代码“能正常跑”，只是因为x86等绝大多数常见平台上，所有同长度的指针（不管是void*还是const int*）的底层内存表示完全一致，函数传参时的二进制调用规则没有差异，所以哪怕类型写错，实际运行时传的参数是对的，程序自然能出正确结果。
但这种行为完全属于C标准定义的未定义行为，没有任何可长期依赖的保障：

• 在部分嵌入式平台、特殊架构的系统上，不同类型的指针可能存在宽度、寻址方式的差异，此时函数类型不匹配会直接导致传参错误，轻则排序逻辑出错，重则触发非法地址访问的崩溃
• 现代编译器的优化器非常激进：只要检测到你传入的函数指针和qsort要求的签名不匹配，它就不会再参考你写的comparison函数的实际逻辑，会按照“标准签名回调”的规则生成优化代码，哪怕当前平台的指针表示完全一致，也可能跑出莫名其妙的错误结果，而且这种问题的排查难度极高。

合规的正确写法 #

• 最稳妥的方案是直接按照qsort要求的回调签名写函数，在函数内部完成指针类型转换，从根源上消除类型不匹配：

int comparison(const void* a, const void* b) {
    const int left = *(const int*)a;
    const int right = *(const int*)b;
    return left - right;
}

这种写法没有任何编译警告，完全符合C标准要求，不存在未定义行为。

• 如果你确实有特殊需求要保留原函数的具体参数签名，就需要在把函数传给qsort时，显式做一次函数指针的强制类型转换，明确告知编译器你已经确认了类型转换的风险：

qsort(arr, 3, sizeof(int), (int(*)(const void*, const void*))comparison);

注：内容的提问来源于stack exchange，提问作者Bamontan