不同字節大小

在C中的文件和網絡的可移植性，fread函數是這樣的：不同字節大小

size_t fread(void *buf, size_t max, FILE *file);

一般字符*陣列用作buf中。人們通常假定char = 8位。但如果它不是真的呢？如果在10位字節系統上讀取以8位字節系統寫入的文件，會發生什麼情況？文件和網絡流在具有不同大小的字節的系統之間的可移植性是否有任何單一標準？最重要的是，如何在這方面編寫可移植代碼？

來源

2012-12-22 lamefun

大概8位字節只是加寬到10位加個零作爲個MSb，因爲它是在這些「奇怪」系統的最大利益是與使用8位字節的世界其他地區的兼容。另外，AFAIK所有這些系統都是「奇怪的」系統（DSP，舊的大型機......），它們通常不處理「常規」機器產生的「常規」文件。 –

對int類型使用新建議的類型定義：uint8_t – stdcall

我剛剛收到關於其他問題的答案，即只有在機器直接支持這些類型定義時纔可以使用這些類型定義。 – lamefun

這些日子裏比特尺寸不是8的系統是非常罕見的。但也有其他尺寸的機器，並且文件不保證可以移動到這些機器上。

如果uberportability是必需的，那麼你將不得不在你的文件中應對char！= 8位的某種編碼。

你有什麼想法可能需要運行在DEC 10或真正舊的IBM大型機，DSP或其他類似的東西，或者你只是想要「我想知道」的目的。如果是後者，我會「忽略這個案子」。這是非常特殊的機器，沒有8位字符 - 而且你很可能會有其他問題，比每個字符的位來使用系統上的「文件」 - 就像如何在那裏得到文件，因爲你可能無法在一個USB記憶棒，插或者FTP傳輸它（儘管後者也許是最有可能的一個）

來源

2012-12-22 16:36:57

關於網絡通信，物理訪問協議（如以太網）確定有多少位有進入一個「信息單元」，並且實施將其映射到適當的類型。所以，對於網絡通信來說，支持奇怪的體系結構沒有問題。

對於文件訪問，如果你想支持怪異的體系結構，東西變得更有趣，因爲沒有標準可以引用，甚至將文件放在系統上的方法可能會影響你如何訪問它們。幸運的是，目前唯一不支持8位字節的系統是DSP和類似的小型嵌入式系統，根本不支持文件系統，所以這個問題基本沒有實際意義。

來源

2012-12-22 17:44:21

不同字節大小

回答

相關問題