Question

考虑到数字可能非常大，使用unsigned long是否安全？

FWIW，我将apache日志中的所有微秒加起来，因此数字可能会非常大。

Answer 1

鉴于您可以在32位平台的unsigned long中存储的最大值大约为4G，这些4G微秒只能转换为71分钟。

在64位平台上（注意Windows长一直是32位，即使在Windows 64位上），那么你可以计算微秒，最多可达到4G分钟71分钟。这是巨大的：大约5800个世纪。

答案：如果你的unsigned long是64位，那就没关系。

Answer 2

使用标准 C存储“真正大”的数字最好的办法是unsigned long long int：

unsigned long long int类型对象的最大值   ULLONG_MAX 18446744073709551615 // 2 ⁶⁴ - 1

这是在C99 +标准中定义的。如果你愿意/想要超越C可以做的事情，还有其他的扩展要考虑，首先想到的是GNU MP Bignum library。

我认为您应该考虑的第三种选择是将gettimeofday()与timeeval结构的方式分解为微秒和秒。这样你就不必进入可笑的数字。如果您想在几微秒内查看数据，您可以自己进行转换。

Answer 3

取决于。正如wikipedia所述，unsigned long保证至少为32位，但我想这可能取决于您的机器。使用32位，您可以表示大小为2 ^ 32 = 4294967296的数字.4294967296微秒是4294秒或超过1小时。

你需要更多吗？如果这样做，请考虑使用保证为64位的unsigned long long，但它是C99。否则，你总是可以将秒分别存储在另一个变量中，就像timeval struct一样。

Answer 4

你可以使用无符号长整数。大小为0到4294967295字节

Answer 5

一个32位无符号整数可以给你大约1小时11分钟，以微秒为单位：

4,294.967295 seconds

另一方面，64位无符号整数将给你超过五十万年。

Answer 6

unsigned long integer is the best option to store big size data.

Answer 7

32位肯定会太小，unsigned long long似乎是正确的选择，它保证至少为64位。或者在unit64_t中使用<inttypes.h>，这在理论上更便于携带。

大约将超过5亿年，这应该足够了。^ _ ^

Answer 8

unistd.h声明useconds_t。

更新引用问题的正文而不是其标题：

使用time_t计算秒数，然后使用useconds_t将剩余部分存储在微秒内。这样可以使您的资源100％便携。

更新2

我刚刚发现我最近的Debian宣称suseconds_t为long int。