使用指向 FILE 类型的 const 指针是个好主意吗?

Is it a good idea to use a const pointer to FILE type?

通常,C 文件 I/O 是使用 FILE* 完成的,因为这是标准库函数所采用的。

在C中,也可以有一个const指针,其中指针的地址不能改变(但它指向的值可以)。

我想知道这是否可以应用于 FILE*,所以写了这个小程序来测试这个:

#include <stdio.h>


int main(void) {
    FILE* const file = fopen("somefile.txt", "w");
    if (file != NULL) {
        fprintf(file, "%s\n", "So this works? That's just swell!");
    }
    return 0;
}

这可以正常编译并使用 GCC 在 Ubuntu/Linux 16.04 上按预期工作(该文件包含我预期的字符串),但我不确定这个习惯用法是否是个好主意 — FILE 类型在设计上是不透明的,对它的处理是特定于实现的。

因为不能保证任何 C 库实现都不会尝试更改 FILE 指针的地址,所以在 C 中执行 I/O 时不使用这种方法是否更安全?

正在按要求将评论转换为答案。

你可以用FILE * const理智;你不能正常使用 const FILE *。可以保证 C 库中的 none 函数将以调用代码可检测到的任何方式修改您传递给它们的 FILE * 的指针部分,因为指针始终按值传递 —从不是指针的地址。因此,调用代码无法修改您的指针 — 除非它为了这样做而执行极其复杂的步骤,而且不会这样做,因为这样做既没有任何必要也没有任何好处。

I'm aware of the difference between FILE * const and const FILE * (as well as why the latter doesn't make any sense). In my question I am seeking to clarify whether making the pointer const will have any negative impact on the standard library functions, as they don't take const pointers in their prototypes.

Also, for context of why I'm looking to do this — the same reasons why one might make any other pointer const: to stop an accidental re-assignment of what it points to.

不能对库中的函数有任何影响;他们被传递了一个值的副本,他们不会修改该值,但不会意识到原始值无论如何都是不可修改的,也不会在意。使用 FILE * const fp = fopen(…); 只是意味着您不能将该文件指针重用于同一函数中的任何其他内容(或重试打开不同的文件名或调用不同的 'open' 函数),并且您不能重置它在你 fclose() 之后为 NULL。当然,如果指针因为在循环内而超出作用域,则在重新进入作用域时可以重用。

否则使用FILE * const无效。我认为这没有用。它没有害处,只是它没有任何好处(并且可能会使人感到困惑)。我建议不要使用 FILE * const.