FILE* 的二进制兼容性答案

【问题标题】：Binary compatibility of FILE*FILE* 的二进制兼容性
【发布时间】：2011-08-03 00:44:02
【问题描述】：

我正在设计进行一些数学计算的 C 库。我需要指定序列化接口才能保存然后加载一些数据。问题是，在库的公共 API 中使用 FILE* 指针是否正确（从二进制兼容性的角度来看）？

目标平台是：

Linux x86、x86_64 与 gcc >= 3.4.6
Windows x86, x86_64 >= WinXP with VS >= 2008sp1

我需要尽可能多地兼容二进制文件，所以目前我的变体如下：

void SMModuleSave(SMModule* module, FILE* dest);
SMModule* SMModuleLoad(FILE* src);

所以我很好奇使用 FILE* 或更好地切换到 wchar*/char* 是否正确？

【问题讨论】：

我终于决定使用文件描述符，因为能够从 python 和 matlab 脚本中使用这个库很重要。这两种语言都提供 fd 但不提供 FILE*。所以我决定使用它，尽管 fileno 不在 c 标准中。
发生了另一个问题：AFAIK 如果它是使用静态 C 运行时（使用 /MT、/MTd）构建的 dll 的 API，则同时使用文件描述符和 FILE* 是不正确的 - @987654321 @。我很迷惑。我真的不想在 API 中使用文件名，因为它只会将使用限制为磁盘上的文件。相反，使用 fd 或 FILE* 可以指定任何流，但静态 CRT 并非如此。我被困住了。 :(

标签： c api binary-compatibility

【解决方案1】：

我什么都不用，但让用户将文件描述符作为int 传递。

然后你可以在你的代码中fdopen()它得到一个FILE*。

然而，当使用 windows 时，它可能不是最好的解决方案，即使它确实有一些帮助函数来获取数字文件描述符。

但是，传递 FILE* 或 const char* 也应该没问题。我更喜欢传递文件名，因为如果库负责打开/关闭文件，则编写的代码更少。

【讨论】：

文件描述符和FILE*在这个用例中大部分是可以互换的，因为你总是可以通过fdopen()和fileno()从另一个中获取一个；但是，其中只有一个是 C 标准库的一部分，我很好奇为什么要选择便携性较差的解决方案？
有几个很好的理由选择文件描述符而不是FILE *：当您需要能够从 IO 错误中恢复时，当您想要执行非阻塞 IO 或控制程序何时执行块，或者当您需要确保在让另一个进程/程序继承打开的文件时不会丢失缓冲区中的输入时。这些似乎都不适用于这里，所以我会使用FILE *。
实际上，我最终决定使用文件描述符，因为能够从 python 和 matlab 脚本中使用这个库很重要。这两种语言都提供 fd 但不提供 FILE*。所以我决定使用它，尽管 fileno 不在 c 标准中。

【解决方案2】：

我不同意 ThiefMaster 的观点：当有等效的可移植解决方案时，原生化（即在 Linux 上使用 int 类型的文件描述符和在 Windows 上使用 void * 类型的句柄）没有任何好处。

我可能会选择FILE *，而不是在库中按名称打开文件：这对库用户来说可能更麻烦，但它也更灵活，因为大多数 libc 实现都提供了各种打开文件的方式(fopen(), _wfopen(), _fdopen(), fdopen(), fmemopen(),...) 而且您不必自己维护单独的宽字符 API。

【讨论】：

是的，这是避免维护单独的宽字符版本的想法。谢谢。

【解决方案3】：

是的，从稳定的二进制接口的角度来看，在这里使用FILE * 是正确的。我认为您可能会将其与使用 FILE 而不是指向它的指针混淆。请注意，您的标准库的 fopen、fgets 等函数都使用（作为参数和返回值）FILE * 类型作为其公共接口的一部分。

【讨论】：

【解决方案4】：

FILE * 是标准的 ANSI/ISO C89 和 C99（甚至 K&R）类型。这是一个便携性的梦想，我更喜欢它而不是其他任何东西。你可以放心使用它。没有比这更好的了。

【讨论】：