对 timeval 成员使用 unsigned long 是否有好处？答案

【问题标题】：Is there a benefit in using unsigned long for timeval members?对 timeval 成员使用 unsigned long 是否有好处？
【发布时间】：2011-05-27 19:56:33
【问题描述】：

我注意到一些程序员将 unsigned long 用于 timeval 的 tv_sec 和 tv_usec [当他们复制或操作它们时]，而它们被定义为简单的 long。

虽然这确实让我想知道为什么当时间通常向前时它们会被这样定义。

【问题讨论】：

标签： c unix time unsigned timeval

【解决方案1】：

对这些变量使用long int 将一直有效，直到year 2038，之后tv_sec 将在long 为4 字节的机器上溢出。

timeval shall be defined as:

The <sys/time.h> header shall define the timeval structure that includes at least the following members:

time_t         tv_sec      Seconds. 
suseconds_t    tv_usec     Microseconds.

您应该注意到time_t 类型被使用而不是long，但在某些系统上它也是 32 位表示，而在其他系统上甚至有 64 位表示。为了避免溢出，time_t 可能会被更改为无符号的 32 位整数或 64 位整数。

这就是为什么有些人使用unsigned long，因为它会阻止溢出直到 2100+ 年。您应该改用time_t 类型，并且您无需考虑您的程序将来应该运行多长时间。

【讨论】：

我不相信这个理由（使用无符号值将 Y2038 问题延迟到 2100 年）。到 2038 年，所有机器都将拥有 64 位（或更大）long，问题就会消失。
@R.. 并非所有嵌入式系统和遗留系统都具有此功能。安全总比后悔好。
time_t 在所有 Unix 系统上都是 long，在 64 位 Unix 系统上是 64 位宽，所以它在实践中永远不会溢出。
28 年很长，大约是 Unix 到现在生命周期的 70%。 @Philipp：Unix 不要求 time_t 是 long。可能是long long。遗憾的是，对于大多数人来说，二进制软件兼容性比修复遗留限制更重要，因此在实践中，我们在 32 位机器上坚持使用 32 位 time_t。
很明显 time_t 将在 2038+ 新发布的任何内容上进行升级。时间_t。即对于任何旨在说桌面用户，甚至拥有自己工作站的商业用户的操作系统都没有问题。除非一个人的目标是真正的旧设备，否则不使用标准方法是很难看的。

【解决方案2】：

当 unix 时间被发明时，负时间可能是有意义的。就像，AT&T 需要足够的时间戳来记录 1960 年代发生的事情。

至于微秒，如果你减去两个值，你可以用带符号的值变成负数，用无符号的值变成 4+十亿。与 0 相比似乎更直观。

【讨论】：

你确定吗？我的理解是(time_t)-1 一直是一个错误指示器，在这种情况下，使用负时间值似乎是可疑的......
time(2) 只有指定返回结果的指针才能返回错误，也就是说返回值只是一个成功的指示。 Gettimeofday 不返回 time_t 开头。也就是说，FreeBSD 的手册页特别警告了 -1。

【解决方案3】：

tv_sec 的类型为 time_t。 tv_usec 的类型为 long，并且需要签名，因为在减去 timeval 值以计算时间间隔时，您将（平均 50% 的时间）在 tv_usec 中得到否定结果，并且您必须检测到这一点并将其转换为来自tv_sec 字段的借用。标准 (POSIX) 可以改为将类型设置为无符号并要求您提前检测包装，但它没有，可能是因为这将更难使用并且与现有做法相矛盾。

在范围方面，tv_usec 也没有理由是无符号的，因为它真正需要能够表示的最大范围是 -999999 到 1999998（或者如果您想累积多个加法，则为数倍/重整化之前的减法）。

【讨论】：