显然,不可能.对于初学者,Linux中只有一个()函数,没有time32()或time64().
搜索一段时间后,我可以看到这不是libc的错误,但是凶手实际上是内核.
为了使libc获取当前时间,需要为其执行系统调用:(Source)
time_t time (t) time_t *t;
{
// ...
INTERNAL_SYSCALL_DECL (err);
time_t res = INTERNAL_SYSCALL (time, err, 1, NULL);
// ...
return res;
}
系统调用定义为:(Source)
SYSCALL_DEFINE1(time, time_t __user *, tloc)
{
time_t i = get_seconds();
// ...
return i;
}
函数get_seconds()返回一个unsigned long,如下所示:(Source)
unsigned long get_seconds(void)
{
struct timekeeper *tk = &timekeeper;
return tk->xtime_sec;
}
而timekeeper.xtime_sec其实是64位:(Source)
struct timekeeper {
// ...
/* Current CLOCK_REALTIME time in seconds */
u64 xtime_sec;
// ...
}
现在,如果你知道你的C,你知道unsigned long的大小实际上是依赖于实现的.在我的64位机器上,它是64位的;但是在这里的32位机器上,它是32位的.在32位实现中可能是64位,但不能保证.
另一方面,u64总是64位,所以在这个基础上,内核跟踪64位类型的时间.为什么它继续返回这个无符号长,这不能保证是64位长,超出了我.
最后,即使libc会强迫time_t持有一个64位的值,也不会改变一个事情.
您可以将应用程序深入到内核中,但我不认为它甚至不值得.