由于 Y2038 問題， Linux Kernel 早在幾年前就已經(jīng)切換到 64 位 time_t，而且發(fā)行版 Alpine 3.13 時也跳到了 64 位 time_t。不過近日，Alpine 安全團隊主管 Ariadne Conill 發(fā)文表示 GNU libc 2.34 在支持 64 位 time_t 上存在缺陷，可能在過渡過程中產(chǎn)生障礙。

訪問：

ECS年終特惠：云服務器低至38元/年起

Alpine 安全團隊主管 Ariadne Conill，圖片來自于 Twitter

如果你密切關(guān)注 Linux 領(lǐng)域的發(fā)展和動向，肯定了解 2038 年錯誤（Year2038 bug）。這個問題之所以會存在，是由于到了 2038 年 1 月 19 日那天，可以用 Unix 帶符號的 32 位整數(shù)時間格式表示的最新時間是 03:14:07 UTC。

可以用 Unix 帶符號的 32 位整數(shù)時間格式來表示的最新時間是 2038 年 1 月 19 日 03:14:07 UTC，這是 1970 年 1 月 1 日之后過了 2147483647 秒。過了那個時間后，由于整數(shù)溢出，時間值將作為負數(shù)來存儲，系統(tǒng)會將日期讀為 1901 年 12 月 13 日，而不是 2038 年 1 月 19 日。

Alpine 操作系統(tǒng)是一個面向安全的輕型 Linux 發(fā)行版。它不同于通常 Linux 發(fā)行版，Alpine 采用了 musl libc 和 busybox 以減小系統(tǒng)的體積和運行時資源消耗，但功能上比 busybox 又完善的多，因此得到開源社區(qū)越來越多的青睞。

在博文中，Conill 表示在 Alpine 使用的 musl C 庫以及許多其他 UNIX C 庫實現(xiàn)中，time_t 在新代碼中總是 64 位的，并且為需要舊的 32 位函數(shù)的代碼提供了兼容性存根（compatibility stubs）。當代碼隨著時間的推移被重建時，它將自動成為符合 Y2038 標準的代碼，而無需任何努力。

微軟在 msvcrt 中又前進了一步：你默認得到 64 位的 time_t，但如果你在編譯時定義了 _USE_32BIT_TIME_T 宏，你仍然可以訪問舊的 32 位函數(shù)。需要注意的是，上面描述的兩種方法都引入了零摩擦，以獲得正確的東西。

GNU 項目為過渡到新的 ABI 所采取的方法正好相反：你必須明確要求新的功能，否則你將永遠得不到它。這種方法為將來改變默認值留下了可能性，但到目前為止，他們從未這樣做過。

這可以從大文件支持擴展中觀察到，需要處理大于 2GiB 的文件，你必須總是用 -D_FILE_OFFSET_BITS=64 來構(gòu)建你的代碼。同樣，如果你在一個 32 位系統(tǒng)上，而你沒有用 -D_TIME_BITS=64 來構(gòu)建你的應用程序，它將不會使用符合 Y2038 的 ABI 來構(gòu)建。

這是最糟糕的方式。考慮一下庫：如果一個依賴關(guān)系是用 -D_TIME_BITS=64 構(gòu)建的，而另一個依賴關(guān)系沒有，并且它們需要相互交換結(jié)構(gòu) timespec 或類似的東西，怎么辦？那么，在這種情況下，你的程序很可能會崩潰或出現(xiàn)奇怪的行為，因為你在編譯的程序中沒有持續(xù)使用相同的結(jié)構(gòu) timespec。

幸運的是，如果你的目標是32位系統(tǒng)，而且你想處理大于2GiB的文件，或者有信心你的代碼在2038年還能繼續(xù)工作，有一些Linux發(fā)行版是建立在Musl之上的，比如Alpine，這將使你不必處理GNU libc的特殊性