我正在设计进行一些数学计算的 C 库。我需要指定序列化接口才能保存然后加载一些数据。问题是，在库的公共 API 中使用 FILE* 指针是否正确（从二进制兼容性的角度来看）？
目标平台有：
我需要尽可能多地兼容二进制文件，所以目前我的变体如下：
void SMModuleSave(SMModule* module, FILE* dest);
SMModule* SMModuleLoad(FILE* src);
所以我很好奇使用 FILE* 或更好地切换到 wchar*/char* 是否正确？
我不同意 ThiefMaster 的观点：当有等效的可移植解决方案时，原生化（即int在 linux 上使用类型的文件描述符和在 Windows 上使用类型的句柄）没有任何好处。void *
我可能会选择FILE *而不是从库中按名称打开文件：这对库用户来说可能更麻烦，但它也更灵活，因为大多数 libc 实现都提供了各种文件打开方式（fopen(), _wfopen(), _fdopen(), fdopen(), fmemopen(), ...) 而且您不必自己维护单独的宽字符 API。
我不会使用，但让用户将文件描述符作为int.
然后你可以fdopen()在你的代码中得到一个FILE*.
然而，当使用 windows 时，它可能不是最好的解决方案，即使它确实有一些帮助函数来获取数字文件描述符。
但是，通过 aFILE*或 aconst char*也应该没问题。我更喜欢传递文件名，因为如果库负责打开/关闭文件，则编写的代码更少。
是的，从稳定的二进制接口的角度来看，在FILE *这里使用是正确的。我想也许你把它与使用FILE而不是指向它的指针混淆了。请注意，您的标准库的fopen、fgets等函数都使用（作为参数和返回值）该FILE *类型作为其公共接口的一部分。
AFILE *是标准的 ANSI/ISO C89 和 C99（甚至 K&R）类型。这是一个便携性的梦想，我更喜欢它而不是其他任何东西。你可以放心使用它。没有比这更好的了。