在Linux的32位程序中，有什么方法可以获取64位的time_t？ [英] Is there any way to get 64-bit time_t in 32-bit programs in Linux?

问题描述

在Windows上，我可以调用：

  _time32（__ time32_t）; //获得32位的time_t 
 _time64（__ time64_t）; //获得64位time_t 
  

（在32和64位程序中）

在Linux中（用GCC编译）有什么办法吗？

解决方案

显然，不可能。对于初学者来说，在Linux中只有一个 time（）函数，没有 time32（）或 time64（）。

搜索了一段时间后，我发现这不是libc的错，但罪魁祸首实际上是内核。

为了使libc能够获取当前时间，它需要对其执行一次系统调用：^（来源）

  time_t时间（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（）; 
 // ... 
返回i; 
} 
  

函数 get_seconds（）返回一个无符号长，如下所示：^{（来源） >}

 无符号长get_seconds（void）
 {
 struct timekeeper * tk =& timekeeper; 
 
 return tk-> xtime_sec; 
} 
  

和 timekeeper.xtime_sec 实际上是64位：^（来源）

<$ p $ code> struct timekeeper {
// ...
/ *当前CLOCK_REALTIME时间，以秒为单位* /
u64 xtime_sec;
// ...
}

现在，如果您知道您的C ，您知道 unsigned long 的大小实际上取决于实现。在我这里的64位计算机上，它是64位；但是在我这里的32位计算机上，它是32位。在某些32位实现中，可能可能是64位，但不能保证。

另一方面， u64 始终为64位，因此从根本上讲，内核保持跟踪时间为64位类型。为什么然后继续将其返回为 unsigned long （不能保证为64位长），这超出了我的范围。

最后，即使libc强制 time_t 保留64位值，也不会

您可以将应用程序深入地绑定到内核中，但是我认为这不值得。

On Windows I can call:

_time32(__time32_t); // to get 32-bit time_t
_time64(__time64_t); // to get 64-bit time_t

(both in 32 and 64-bit programs)

Is there any way do this in Linux (compiling with GCC)?

解决方案

Apparently, no it's not possible. For starters, there is only one time() function in Linux, no time32() or time64().

After searching for a while, I can see that it's not libc's fault, but the culprit is actually the kernel.

In order for libc to fetch the current time, it need to execute a system call for it: ^(Source)

time_t time (t) time_t *t;
{
    // ...
    INTERNAL_SYSCALL_DECL (err);
    time_t res = INTERNAL_SYSCALL (time, err, 1, NULL);
    // ...
    return res;
}

The system call is defined as: ^(Source)

SYSCALL_DEFINE1(time, time_t __user *, tloc)
{
    time_t i = get_seconds();
    // ...
    return i;
}

The function get_seconds() returns an unsigned long, like so: ^(Source)

unsigned long get_seconds(void)
{
    struct timekeeper *tk = &timekeeper;

    return tk->xtime_sec;
}

And timekeeper.xtime_sec is actually 64-bit: ^(Source)

struct timekeeper {
    // ...
    /* Current CLOCK_REALTIME time in seconds */
    u64                     xtime_sec;
    // ...
}

Now, if you know your C, you know that the size of unsigned long is actually implementation-dependant. On my 64-bit machine here, it's 64-bit; but on my 32-bit machine here, it's 32-bit. It possibly could be 64-bit on some 32-bit implementation, but there's no guarantee.

On the other hand, u64 is always 64-bit, so at the very base, the kernel keeps track of the time in a 64-bit type. Why it then proceeds to return this as an unsigned long, which is not guaranteed to be 64-bit long, is beyond me.

In the end, even if libc's would force time_t to hold a 64-bit value, it wouldn't change a thing.

You could tie your application deeply into the kernel, but I don't think it's even worth it.

这篇关于在Linux的32位程序中，有什么方法可以获取64位的time_t？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！