有修复 Unix 千年错误或 Y2k38 问题的指针吗？
我一直在回顾 2038 年问题（Unix Millennium Bug）。
我在维基百科上阅读了有关此问题的文章，其中我读到了有关此问题的解决方案。
现在我想将 time_t 数据类型更改为无符号 32 位整数，这将使我能够存活到 2106 年。我在 PowerPC 上有带有 RTPatch 的 Linux 内核 2.6.23。
是否有可用的补丁可以让我将 PowerPC 的 time_t 数据类型更改为无符号 32 位整数？或者有什么补丁可以解决这个bug？
I've been reviewing the year 2038 problem (Unix Millennium Bug).
I read the article about this on Wikipedia, where I read about a solution for this problem.
Now I would like to change the time_t data type to an unsigned 32bit integer, which will allow me to be alive until 2106. I have Linux kernel 2.6.23 with RTPatch on PowerPC.
Is there any patch available that would allow me to change the time_t data type to an unsigned 32bit integer for PowerPC? Or any patch available to resolve this bug?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
time_t实际上是在您的libc实现中定义的，而不是内核本身。内核提供了各种提供当前时间的机制（以系统调用的形式），其中许多机制已经支持超过 32 位的精度。问题实际上是您的
libc实现（大多数桌面 Linux 发行版上的glibc），它在从内核获取时间后，以以下形式将其返回给您的应用程序： 32 位有符号整数数据类型。虽然理论上可以更改
libc实现中time_t的定义，但实际上这会相当复杂：这样的更改会更改libc的 ABI code>，反过来要求每个使用libc的应用程序也从源代码重新编译。最简单的解决方案是将系统升级到 64 位发行版，其中
time_t已定义为 64 位数据类型，从而完全避免该问题。time_tis actually defined in yourlibcimplementation, and not the kernel itself.The kernel provides various mechanisms that provide the current time (in the form of system calls), many of which already support over 32-bits of precision. The problem is actually your
libcimplementation (glibcon most desktop Linux distributions), which, after fetching the time from the kernel, returns it back to your application in the form of a 32-bit signed integer data type.While one could theoretically change the definition of
time_tin yourlibcimplementation, in practice it would be fairly complicated: such a change would change the ABI oflibc, in turn requiring that every application usinglibcto also be recompiled from sources.The easiest solution instead is to upgrade your system to a 64-bit distribution, where
time_tis already defined to be a 64-bit data type, avoiding the problem altogether.关于此处建议的 64 位发行版，我可以指出实施该发行版时遇到的所有问题吗？嵌入式行业有很多32位NONPAE计算机。用 64 位计算机替换它们将是一个大问题。每个人都习惯了经常更换/升级的桌面。所有 Linux 操作系统供应商都需要认真提供不同的选择。这并不是说 32 位计算机有缺陷、无用或 16 年后就会报废。它不需要64位计算机来监视模拟输入、控制设备和报告警报。
About the suggested 64-bit distribution suggested here, may I note all the issues with implementing that. There are many 32-bit NONPAE computers in the embedded industry. Replacing these with 64-bit computers is going to be a LARGE problem. Everyone is used to desktop's that get replaced/upgraded frequently. All Linux O.S. suppliers need to get serious about providing a different option. It's not like a 32-bit computer is flawed or useless or will wear out in 16 years. It doesn't take a 64 bit computer to monitor analog input , control equipment, and report alarms.