在Windows上我可以打电话:
_time32(__time32_t); // to get 32bit time_t
_time64(__time64_t); // to get 64bit time_t
(32位和64位程序)
在Linux中有没有办法做到这一点(用GCC编译)？
net*_*der 13
显然,不,这是不可能的.对于初学者来说,time()Linux中只有一个功能,没有time32()或time64().
在搜索了一段时间后,我可以看到它不是libc的错,但罪魁祸首实际上是内核.
为了libc中获取当前时间,它需要执行一个系统调用它:(来源)
time_t time (t) time_t *t;
{
// ...
INTERNAL_SYSCALL_DECL (err);
time_t res = INTERNAL_SYSCALL (time, err, 1, NULL);
// ...
return res;
}
该系统呼叫被定义为:(源)
SYSCALL_DEFINE1(time, time_t __user *, tloc)
{
time_t i = get_seconds();
// ...
return i;
}
该函数get_seconds()返回一个unsigned long,如下所示:(源)
unsigned long get_seconds(void)
{
struct timekeeper *tk = &timekeeper;
return tk->xtime_sec;
}
而timekeeper.xtime_sec实际上是64位:(来源)
struct timekeeper {
// ...
/* Current CLOCK_REALTIME time in seconds */
u64 xtime_sec;
// ...
}
现在,如果你知道你的C,你知道它的大小unsigned long实际上是依赖于实现的.在我的64位机器上,它是64位; 但在我的32位机器上,这是32位.在某些32位实现上它可能是64位,但不能保证.
另一方面,u64总是64位,所以在最基础上,内核以64位类型跟踪时间.为什么然后它继续返回这个unsigned long,不保证是64位长,超出了我.
最后,即使libc强制time_t保持64位值,它也不会改变.
您可以将应用程序深深地绑定到内核中,但我认为它甚至不值得.
上面的许多答案都说这是不可能的，但这是完全不正确的。这在当时是不可能的，但人们多年来一直在谈论修复它。最后，通过添加新的syscalls将32 位平台上的 64 位时间支持引入到 Linux 5.1 内核中。查看此表，您可以看到这些系统调用仅在 32 位平台上可用。现在，如果您正在为 32 位系统编写代码，则可以直接调用（从内联汇编或 C with ）以获取当前时间*time64clock_gettime64syscall()
但是在那之后你就完全靠自己了。如果您想要完整的用户空间支持，您必须使用 Linux 5.6 或更高版本以及 musl 1.2+ 或 glibc 2.32+。只需重建您的代码，您的代码time_t就会变成 64 位长
所有用户空间都必须使用 64 位 编译
time_t，这将在即将到来的 musl-1.2 和 glibc-2.32 版本以及来自 linux-5.6 或更高版本的已安装内核头文件中得到支持。直接使用系统调用接口的应用程序需要移植以使用
time64linux-5.1 中添加的系统调用来代替现有的系统调用。这会影响大多数用户futex()和seccomp()以及编程语言有自己的运行环境不是基于libc中。
想要查询更多的信息
time64()/time32()标准库中不包含任何功能.
time32_t/time64_t标准标题中没有考虑任何定义.
time_t被定义time.h为typedef __time_t time_t;
经过长链重新定义后,您会发现__time_t在32位计算机上定义为32位,在64位计算机上定义为64位.