有没有办法让在Linux 32位程序64位的time_t [英] Is there any way to get 64-bit time_t in 32-bit program in Linux

查看:2458
本文介绍了有没有办法让在Linux 32位程序64位的time_t的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

在Windows上我可以打电话:

On Windows I can call:

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

(均在32和64位的程序)

(both in 32 and 64 bit programs)

有没有办法做到这一点在Linux中(用gcc编译)?

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

推荐答案

显然,没有这是不可能的。对于初学者来说,有在Linux中,没有 time32()只有一个时间()函数或 time64()

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

搜索一段时间后,我可以看到,它不是libc中的过错,但罪魁祸首其实是内核。

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

为了libc中获取当前的时间,它需要执行一个系统调用它:(<一个href=\"http://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/unix/sysv/linux/time.c;h=d447d3caa1eb6d47727ea6cc5cc73e5edbec43ba;hb=HEAD#l30\">Source)

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;
}

的系统,呼叫被定义为:(<一href=\"http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=blob;f=kernel/time.c;h=d226c6a3fd28933d02edd485a9c8353db2212c02;hb=406089d01562f1e2bf9f089fd7637009ebaad589#l62\">Source)

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

功能 get_seconds()返回无符号长,就像这样:(<一个href=\"http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=blob;f=kernel/time/timekeeping.c;h=cbc6acb0db3fafbaa4830da34cdb22e538892764;hb=406089d01562f1e2bf9f089fd7637009ebaad589#l1296\">Source)

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

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

    return tk->xtime_sec;
}

timekeeper.xtim​​e_sec 实际上是64位:(<一个href=\"http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=blob;f=include/linux/timekeeper_internal.h;h=e1d558e237ecfdd8059106c4e98f488ff406ff12;hb=406089d01562f1e2bf9f089fd7637009ebaad589#l30\">Source)

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

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

现在,如果你知道你的C,你知道,的大小无符号长实际上是依赖于实现的。在我的64位机在这里,它是64位;但我的32位机在这里,它是32位的。它的可能的可能是一些32位实现64位,但没有保证。

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.

在另一方面, U64 始终是64位,因此在非常基础的,内核跟踪的时间在64位的类型。为什么然后继续返回这是一个无符号长,这是不能保证是64位​​长,是超越我。

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.

在最后,即使libc中的将迫使 time_t的保留64位值,它不会改变任何事情。

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屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆