C pread 给出不同的结果

Question

我有两个系统。一个是 Intel CPU 上的 Ubuntu 14.04 64bit，另一个是 CubieTruck 上的 ARM 的 Ubuntu 14.04。

英特尔系统有一个数据文件存储在 ext4 格式的硬盘上。 CubieTruck 在 NTFS 硬盘上具有相同的文件，该硬盘使用 NTFS-3G 挂载。

我目前在这些系统上遇到了 pread() 的问题。我从一个文件中读取了一堆字节，并从这个块中打印出前 64 个字节。稍后，这些字节用于使用 Shabal 计算一些哈希。

虽然 CubieTruck 上打印的数据与我在使用 Hex 编辑器打开文件时在 Windows 系统上看到的完全一致，但在 64 位 Ubuntu 上的输出却不同。看起来像是充满了“FFFFFF”，但总体上也有所不同。更奇怪的是，虽然 CubieTruck 上的输出始终保持不变，但在 64 位 Ubuntu 系统上它会在一段时间后发生变化（这种情况发生时我还没有看到模式，我只是不时检查）。

但最烦人的是，x64系统似乎计算正确，而ARM系统却错了。

我不知道为什么 pread 在这些系统下为同一个文件提供不同的结果，但我希望有人能对此有所了解。

编辑，代码：

int main(int argc, char **argv) {
    unsigned int readsize = 16384 * 32 * 2;
    char *cache = (char*) malloc(readsize);

    int fh = open("/home/user/somefile", O_RDONLY);

    if (fh < 0) {
        printf("can't open file");
        exit(-1);
    }

    int bytes = 0, b;

    do {
        b = pread(fh, &cache[bytes], readsize - bytes, bytes);
        bytes += b;
    } while(bytes < readsize && b > 0);

    int i = 0;
    for (i=0; i < 64; i++) {
        printf("%02X", cache[i]);
    }

    close(fh);
    free(cache);
    return 0;
}

两个系统都打开完全相同的文件。

x64 上的结果： FFFFFF94FFFFFFF16D25FFFFFFC0FFFFFFA3367D010BFFFFFFEF1E12FFFFFF841CFFFFFFBE4C26FFFFFF92FFFFFF80FFFFFF86FFFFFFA822FFFFFF8A26FFFFFF906CFFFFFFAD05FFFFFFE7FFFFFFB124FFFFFFA8FFFFFFF77B16FFFFFFEAFFFFFFACFFFFFF9DFFFFFF9EFFFFFF81FFFFFFC7FFFFFF92FFFFFFCDFFFFFFB0FFFFFFE86270FFFFFFF974FFFFFFA8420C45FFFFFFFC04FFFFFFF9103F2E3A47FFFFFF990F

ARM 上的结果： 94F16D25C0A3367D010BEF1E12841CBE4C26928086A8228A26906CAD05E7B124A8F77B16EAAC9D9E81C792CDB0E86270F974A8420C45FC04F9103F2E3A47990F

您可以看到，在 x64 上，结果充满了“FFFFFF”，而且看起来，这在以后以某种方式需要。但我不明白为什么它在我的系统上有所不同。

Answer 1

C 的一个有趣方面是实现定义的行为的数量 - 在本例中为 whether char is signed or not。

%x 格式说明符采用 unsigned int 参数，因此在 ARM 情况下转换很简单 - char 是无符号的，因此只需将零扩展为 unsigned int。但是对于已签名的 x86，转换可以采用以下两种方式之一：

• 将char 符号扩展为signed int，然后将其转换为unsigned int
• 首先转换为unsigned char，然后零扩展为unisgned int

看来转换的 char->int 部分优先于有符号的->无符号的部分^* 所以你得到前者（注意字节如何没有最高位集是明确的，并且在两种实现上都打印相同）。我想您的计算在期望有符号的地方进行了类似的转换，因此它在 ARM 上会中断。

简而言之，如果您处理的是字符大小的值而不是字符，总是指定signed char或unsigned char视情况而定，永远不要裸露char。

_{* 我想我可以挖掘出标准来检查它是否真的被指定了，但在这一点上它只是一个琐碎的细节}