使用标准 C 库将文件读取到内存 - Windows 过早识别 EOF 但适用于 Mac、Linux

Posted 2023-02-22

【中文标题】使用标准 C 库将文件读取到内存 - Windows 过早识别 EOF 但适用于 Mac、Linux

【英文标题】：Reading a file to memory using standard C library - Windows prematurely identifies EOF but works on Mac,Linux

【发布时间】：2020-05-16 07:16:35

【问题描述】：

这感觉像是 dumbest 问题，但希望有人能提供帮助。抱歉这篇文章太长了，但我想提供足够的细节，以免人们建议我已经尝试过的东西。

我发现了一个我编写的 C 程序的问题，该程序应该在 Mac、Linux 和 Windows 上发布。该程序无法在 Windows 上运行，但可以在 Mac 和 Linux 上正常运行，并且在最近进行更改之前曾经在 Windows 上运行。

失败的直接原因与将文件读入内存块有关 - 所以我只将该代码隔离到一个独立的程序中，并使用一些示例数据对其进行测试，这些数据在 Windows 上可靠地失败并在 Mac 上正常工作Linux。

需要注意的是，在 Windows 上，我使用的是 Visual Studio 2019（版本 16.5.5）。我正在 64 位戴尔笔记本电脑上使用 Windows 10 Enterprise 对其进行测试。在 Linux 上，我使用 gcc（我正在使用 Ubuntu 20.04 对其进行测试）。在 mac 上，我使用 clang 编译它。该程序旨在可移植（至少在这三个平台之间）。

加载文件的基本策略是使用 fopen() 打开文件，然后使用 fseek() 测量文件，将文件标记移动到文件末尾，使用 ftell() 获取文件内的位置文件，然后 fseek() 回到开头，然后使用 ftell() 获取文件开头的位置（实际上通常为零，但不能保证），然后我从结束位置来确定文件大小。这个“测量文件”代码在实践中似乎可以可靠地测量我关心的三个平台上的文件。

然后，我调用 malloc() 分配一块足够大的内存来保存文件。这总是很好。我使用的文件大约是 200K，它们是二进制文件——但出于隔离目的，我能够让它可靠地失败，使用 271 字节的文件。原始代码只是使用了一个从 0 到文件大小的 for 循环，并反复调用 getc(fileptr)，然后将每个字节分配到内存缓冲区中。然后它关闭了文件。此代码在 Mac 和 Linux 上运行良好，但在 Windows 上无法运行。我观察到的是我会得到文件的第一部分——在某些情况下是文件的大部分——然后我会开始从 getc(fileptr) 调用中读回“ff”，这将填满内存的其余部分- 显然是错误的。

所以我研究了 getc() 和 fgetc() 之间的区别，显然 getc() 有时可能是一个不止一次评估事物的宏。这似乎不是一个明显的罪魁祸首，但我还是改成了 fgetc() 并没有改变任何东西。我还将 malloc() 调用更改为 calloc()，这样我就可以从全零开始，并且更容易看到使用调试器读取的文件（即查看内存缓冲区并看到它被写入）。

我使用 Hex 编辑器创建了一个包含以下数据的文件，以便我可以使用它进行更系统的测试。该文件包含 271 个字节。前 256 个字节是所有可能的字节值：00 01 02 03 ... fc fd fe ff。最后 16 个字节是 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f。这样我可以查看问题是否是由尝试读取某些特定字节值引起的，并且我可以让它继续通过所有可能的字节值并以相同的模式再执行 16 个字节，只是为了更好地衡量，我可以很容易地看到是否最后一个字节是 0f。

接下来我使用预处理器#if 0/#if 1 在使用 fgetc() 的文件读取版本和使用 fread() 的版本之间切换。这是我得到关于可能发生的事情的第一个有趣线索的地方。

在 Mac/Linux 上，该程序的两个版本都可以正确打印我期望的值。但是，在 Windows 上，fread() 版本读取前 26 个字节，之后所有字节为 00（因为 calloc 将整个块的值设置为 00，而 fread() 仅设置前 26 个字节）。文件读取的getc()版本正确读取了前26个字节，然后后面的所有字节都是ff。

前26个字节为：0x00 0x01 0x02 0x03 0x04 0x05 0x06 0x07 0x08 0x09 0x0a 0x0b 0x0c 0x0d 0x0e 0x0f 0x10 0x11 0x12 0x13 0x14 0x15 0x016 0x15 18 0x16

该程序在 Mac 上的完整（正确）输出为：

sz 文件：271 读取 271 个字节 load_ggx_file: 0 0x00 0x01 0x02 0x03 0x04 0x05 0x06 0x07 0x08 0x09 0x0a 0x0b 0x0c 0x0d 0x0e 0x0f 0x10 0x11 0x12 0x13 0x14 0x15 0x16 0x17 0x18 0x19 0x1a 0x1b 0x1c 0x1d 0x1e 0x1f 0x20 0x21 0x22 0x23 0x24 0x25 0x26 0x27 0x28 0x29 0x2a 0x2b 0x2c 0x2d 0x2e 0x2f 0x30 0x31 0x32 0x33 0x34 0x35 0x36 0x37 0x38 0x39 0x3a 0x3b 0x3c 0x3d 0x3e 0x3f 0x40 0x41 0x42 0x43 0x44 0x45 0x46 0x47 0x48 0x49 0x4a 0x4b 0x4c 0x4d 0x4e 0x4f 0x50 0x51 0x52 0x53 0x54 0x55 0x56 0x57 0x58 0x59 0x5a 0x5b 0x5c 0x5d 0x5e 0x5f 0x60 0x61 0x62 0x63 0x64 0x65 0x66 0x67 0x68 0x69 0x6a 0x6b 0x6c 0x6d 0x6f 0x70 0x71 0x72 0x73 0x74 0x75 0x76 0x77 0x78 0x79 0x7a 0x7b 0x7c 0x7d 0x7e 0x7f 0x80 0x81 0x82 0x83 0x84 0x85 0x86 0x87 0x88 0x89 0x8a 0x8b 0x8c 0x8d 0x8e 0x8f 0x90 0x91 0x92 0x93 0x94 0x95 0x96 0x97 0x98 0x99 0x9a 0x9b 0x9c 0x9d 0x9e 0x9f 0xa0 0xa1 0xa2 0xa3 0xa4 0xa5 0xa6 0xa7 0xa8 0xa9 0xaa 0xab 0xac 0xad 0xae 0xaf 0xb0 0xb1 0xb2 0xb3 0xb4 0xb5 0xb6 0xb7 0xb8 0xb9 0xba 0xbb 0xbc 0xbd 0xbe 0xbf 0xc0 0xc1 0xc2 0xc3 0xc4 0xc5 0xc6 0xc7 0xc8 0xc9 0xca 0xcb 0xcc 0xcd 0xce 0xcf 0xd0 0xd1 0xd2 0xd3 0xd4 0xd5 0xd6 0xd7 0xd8 0xd9 0xda 0xdb 0xdc 0xdd 0xde 0xdf 0xe0 0xe1 0xe2 0xe3 0xe4 0xe5 0xe6 0xe7 0xe8 0xe9 0xea 0xeb 0xec 0xed 0xee 0xef 0xf0 0xf1 0xf2 0xf3 0xf4 0xf5 0xf6 0xf7 0xf8 0xf9 0xfa 0xfb 0xfc 0xfd 0xfe 0xff 0x00 0x01 0x02 0x03 0x04 0x05 0x06 0x07 0x08 0x09 0x0a 0x0b 0x0c 0x0d 0x0e 0x0f

在窗口上使用它打印的 fread() 版本：

sz 文件：271 错误：0 feof: 1 读取 26 个字节 load_ggx_file: 0 0x00 0x01 0x02 0x03 0x04 0x05 0x06 0x07 0x08 0x09 0x0a 0x0b 0x0c 0x0d 0x0e 0x0f 0x10 0x11 0x12 0x13 0x14 0x15 0x16 0x17 0x18 0x19 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00

在 Windows 上，当 fread 返回的值低于您要求的值（即我的情况下的第三个参数）时，您应该检查 ferror() 和 feof()。我发现 ferror() 返回 0 并且 feof() 返回 1。所以问题似乎是 Windows 认为它​​已到达文件末尾。问题是它为什么会这样认为，考虑到我的限制，什么是合理的替代方案？ （即我想只使用标准库编写可移植的 C 代码 - 而不是一堆特定于平台的代码）。

我确实检查了问题是否仅仅是由于 0x20 字符造成的。我尝试使用十六进制编辑器在我的测试文件中的 0x01 之后插入一个 0x20，发生的事情是它读取并打印了该字符只是文件的表示，并且仍然在 0x19 字符之后停止。似乎没有任何特定的角色总是导致它窒息。

这是完整的测试程序：

#include <stdio.h>
#include <stdlib.h>
#include <assert.h>

typedef struct 
    long long szFile;
    unsigned char* ggx_file;
 ggx_t;

int load_ggx_file(const char* ggx_file_path, ggx_t* outGGX)

    int rc;
    FILE* ggx_file;
    unsigned char c;
    long long szFile;
    long fend_offset;
    long fstart_offset;

    ggx_file = fopen(ggx_file_path, "r");
    if (!ggx_file || NULL == outGGX) 
        return -1;
    
    rc = fseek(ggx_file, 0, SEEK_END);
    assert(0 == rc);
    fend_offset = ftell(ggx_file);

    rc = fseek(ggx_file, 0, SEEK_SET);
    assert(0 == rc);

    fstart_offset = ftell(ggx_file);
    szFile = fend_offset - fstart_offset;

    printf("szFile: %lld\r\n", szFile);

    outGGX->szFile = szFile;
    outGGX->ggx_file = (unsigned char*)calloc(szFile, 1);

    int i = 0;
#if 0
    for (; i < szFile; ++i) 
        c = fgetc(ggx_file);
        outGGX->ggx_file[i] = c;
    
#else
    i = fread(outGGX->ggx_file, 1, szFile, ggx_file);
    if (i < szFile) 
        int rc2;
        rc2 = ferror(ggx_file);
        printf("ferror: %d\r\n", rc2);
        rc2 = feof(ggx_file);
        printf("feof: %d\r\n", rc2);
    
#endif

    printf("Read %d bytes\r\n", i);

    fclose(ggx_file);

    return 0;


int main(int argc, const char* argv[]) 

    const char * ggx_file_path = argv[argc - 1];

    ggx_t ggx_file;
    int rc = load_ggx_file(ggx_file_path, &ggx_file);

    printf("load_ggx_file: %d\r\n", rc);

    for (int i = 0; i < ggx_file.szFile; ++i) 
        printf("0x%02x ", ggx_file.ggx_file[i]);
        if (0 == ((i+1) % 20)) 
            printf("\r\n");
        
    
    printf("\r\n");
    return 0;

【问题讨论】：

fopen(..., "rb")

这是正确答案。完全解决了我的问题。非常感谢。我不确定如何将此标记为已回答，但这是正确答案。

有很多文字描述了一个由缺少单个字符引起的非常常见的问题。

【参考方案1】：

您希望以二进制模式（而不是文本模式）打开文件。 在 Un*x 下也是如此，在 Windows 下它会阻止库将磁盘中的某些数据替换为内存中的不同数据，例如 "\r\n" 变为 "\n"； "\x1B" 信号 EOF, ...

fopen(..., "rb") // same as "r" in Un*x

【讨论】：

（这是 CP/M 中的一个有用功能，其中不存储文件的确切长度（仅存储使用的扇区数），而是用 0x1b 字符填充数据。）

很高兴知道@LorinczyZsigmond，谢谢。所以 Windows 保持了对一个死了近 40 年的系统的一些向后兼容性？ xD