Valgrind检测到FILE*无效读取：为何触发重复释放告警？

兄弟，你这个问题踩中了C语言里非常经典的一个坑——函数参数是值传递，咱们一步步拆解为什么Valgrind会报这个错：

先捋清楚代码的执行逻辑： #

1. 在main里，你成功打开test.txt，拿到了一个FILE*类型的指针fout，然后把它传给了otherfunc。
2. 进入otherfunc后：
   • 第4行的fclose(fout)确实关闭了正确的文件，但同时也把这个FILE结构体对应的内存给释放了。
   • 第5行你重新fopen得到了一个新的文件指针，但注意：你把这个新指针赋值给的是otherfunc内部的fout参数——这个参数只是main里原fout的副本！修改副本完全不会影响main里的那个原指针。
3. 回到main的第24行，你调用fclose(fout)的时候，这里的fout还是之前那个已经被释放了内存的旧指针！相当于你拿着一个指向“已回收垃圾”的地址去操作，Valgrind当然会给你报无效读取的警告。

你觉得“每次fclose都对应fopen”这个逻辑没错，但问题出在：otherfunc里新打开的文件指针根本没传回给main，main从头到尾都拿着那个已经失效的旧指针，最后相当于重复close了一个已经被释放的内存块。

两种简单的修复方案： #

方案1：让otherfunc返回新的文件指针

直接把新打开的指针返回给main，更新原指针的值：

FILE* otherfunc(FILE* fout){
    fclose(fout);
    fout = fopen("test.txt", "w");
    setbuf(fout, 0);
    return fout; // 返回新的指针
}

// main里调用时改成：
fout = otherfunc(fout);

方案2：用双重指针（指针的指针）传参

这种方式可以直接修改main里的原指针变量，不需要返回值：

void otherfunc(FILE** fout){
    fclose(*fout); // 解引用操作原指针指向的文件
    *fout = fopen("test.txt", "w"); // 修改原指针的值，让它指向新打开的文件
    setbuf(*fout, 0);
}

// main里调用时传指针的地址：
otherfunc(&fout);

不管用哪种方案，都能确保main里的fout最终指向的是otherfunc里新打开的有效文件指针，避免后续的无效内存操作。

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