C++ 64位文件I/O陷阱

將C++應用程序從32位轉換爲64位Linux時，發現了一個有趣的錯誤。我們的FileStore類實現了將結構保存到/從文件中恢復。除了一種方法之外，它總是在每個操作之前和之後調用fopen（）和fclose（）。在32位平臺上的這個（buggy）方法中，即使該文件之前已通過其他方法的fclose（）'d，它也可以正確無誤地執行fseek（）和fread（）。在64位平臺上，每次在fread（）上都會崩潰。我猜測在32位平臺上，即使在fclose（）之後底層的FILE結構仍然存在，因此它仍然可以被訪問。有沒有人有任何進一步的信息，爲什麼這種差異和任何其他陷阱與64位文件I/O？C++ 64位文件I/O陷阱

來源

2011-03-04 Mr.Dirty.Birdy

未定義的行爲總是會改變。在'fclose'd流上執行操作是UB。請參閱http://pubs.opengroup.org/onlinepubs/009695399/functions/fclose.html – KitsuneYMG 2011-03-04 00:56:41

人們仍然想知道導致不同行爲的兩種不同實現是什麼，特別是如果在兩種情況下該行爲看起來一致。 – 2011-03-04 01:35:54

是的，這是好奇的行爲的一致性。它可能只是簡單地說，64位GCC 4.1.2運行時總是在fclose（）後清理FILE結構，而32位不是，但我期望運行時將遵循相同的低級步驟。 – 2011-03-04 02:18:46

這聽起來像對我來說未定義的行爲。你的問題的64位與32位方面是一個紅色的鯡魚。編譯器可以自由清除你的主目錄，或者在這種情況下提交聯邦納稅申報表。

來源

2011-03-04 00:55:22

事實上，這個問題不是64位與32位 - 這只是純粹的（不）運氣。這裏的每個測試用例在使用FILE *之後都會導致崩潰，32位或64位。 – nos 2011-03-04 00:58:40

它是「在調用fclose（）之後，任何流的使用都會導致未定義的行爲。」來自 – KitsuneYMG 2011-03-04 00:58:46

謝謝 - 我同意你不能依賴於如果你在fclose（）之後使用FILE會發生什麼;就像你說的那樣，在32位上可能只是運氣不好，而沒有立即清理掉。大概你是對的，64位是一個紅鯡魚...只是好奇，因爲我們正在經歷一個64位轉換演習，不想錯過任何東西。 – 2011-03-04 01:15:08

C++ 64位文件I/O陷阱

回答

相關問題