C语言通过void*实现类型无关函数的合理性与隐患咨询

合法性判定 #

你这种通过void*接收任意类型数组、手动传入元素单步大小实现类型无关逻辑的写法，是C语言标准完全认可的合法实现，不属于未定义行为。C标准库自带的qsort排序、bsearch二分查找等通用工具函数，用的就是完全一致的实现思路，不存在语言层面的合规性问题。

现有实现的隐患与问题 #

你觉得“实现简单没见人广泛用”的感受，一半来自这种方案本身的固有取舍，一半来自你当前写的代码本身藏着bug：

• 首先是测试代码的低级笔误：测试float数组b时，你传给pop_array的还是int数组a的指针，而且调用时漏传了sizeof(float)的元素大小参数，这段代码实际运行必然触发内存错误，只是你贴示例时手滑写错了，不属于方案本身的问题。
• 核心指针偏移逻辑有错误：你当前计算目标地址的写法是(unsigned char*) array + index + type，这是完全错误的。数组元素的地址偏移规则是「元素地址 = 数组首地址 + 元素索引 * 单元素大小」，你直接把index当字节数加，相当于少算了index*(type-1)个字节的偏移。之前你测试能跑出正确结果纯粹是巧合：测试用的索引是2、int大小是4，你算出来的偏移是6字节，正确偏移是8字节，memmove覆盖时刚好没踩到影响输出的内存位置，换个索引或者换个8字节的double类型测试，立刻会出现内存篡改、输出乱码的问题。正确的地址计算逻辑应该是：

int pop_array(void *array, int index, int size, int element_size) {
    if (index >= size || !array || element_size <=0) return 0;
    unsigned char *pos = (unsigned char*)array + index * element_size;
    memmove(pos, pos + element_size, element_size * (size - index - 1));
    return 1;
}

• 完全丢失编译期类型检查：这是这种方案最核心的缺陷。编译器不会再校验你传入的数组类型和传入的元素大小是否匹配——比如你传int数组却填sizeof(double)当元素大小、传错数组长度，编译器不会给出任何警告，程序会直接出现内存越界、数据篡改的问题，排查成本很高。
• 功能逻辑不完整：当前函数只做了内存覆盖，没有维护数组的有效长度，也没有处理动态数组的缩容逻辑，如果用于堆上分配的动态数组，会持续占用多余内存，不过这属于功能设计缺失，和void*的实现方案无关。

为什么这种方案没有在所有场景普及 #

这种写法其实在底层通用库、基础工具组件里用得非常普遍，只是在上层业务代码里很少直接裸用：

• 上层业务开发更倾向于类型安全，宁愿用宏批量生成不同类型的强版本函数、或者用C11的_Generic做编译时类型分发，也不想承担参数传错就触发内存错误的风险。
• 裸用void*的接口对调用方不友好，调用方必须每次手动传元素大小、自己记着维护数组长度，接口易用性比强类型函数差很多。

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