它是安全的存儲毫秒紀元以來UINT32

我目前正在重寫一些舊的代碼和跨越這來了：它是安全的存儲毫秒紀元以來UINT32

gettimeofday(&tv, NULL); 
unsigned int t = tv.tv_sec * 1000 + tv.tv_usec/1000;

這確實看起來他們正試圖紀元以來的毫秒存儲在一個UINT32 。當然，我認爲這不合適，所以我做了一些測試。

#include <sys/time.h> 
#include <stdint.h> 

int main() { 
    struct timeval tv; 
    gettimeofday(&tv, nullptr); 
    uint32_t t32 = tv.tv_sec * 1000 + tv.tv_usec/1000; 
    int64_t t64 = tv.tv_sec * 1000 + tv.tv_usec/1000; 
    return 0; 
}

而且我有種權：

(gdb) print t32 
$1 = 1730323142 
(gdb) print t64 
$2 = 1423364498118

所以我想這是不是安全的，他們在做什麼。但他們在做什麼，爲什麼他們這樣做，實際發生了什麼？ （在這個例子中，左邊的10位會丟失，他們只關心差異）他們仍然保持毫秒的精度嗎？ （是）請注意，他們通過網絡發送此「時間戳」，並仍將其用於計算。

來源

2015-02-08 noob

我想你引用的代碼試圖產生一個隨機數發生器的種子。 – 2015-02-08 03:17:46

@HotLicks不，它不是。 – noob 2015-02-08 03:18:26

（還需要回想一下'int'不一定是32位。） – 2015-02-08 03:19:18

不，這不是「安全」的：它犧牲了便攜性，準確性或兩者兼而有之。

如果您只關心低位（例如，如果你在網絡上發送這些時間，然後在另一側差異大約400萬秒（46天）的差異。

如果您只在int爲64位的系統上運行此代碼，這是正確的。有一些這樣的機器，但不是很多。

來源

2015-02-08 03:40:47

更安全嗎？我可以回答不，是的。我說不是，因爲在這一天，我們使用幾乎所有的位（從一個32位的數字）來計算自1970年1月以來的時代。當你乘以1000（十進制）時，你幾乎將所有位旋轉到左邊更接近10位，這意味着失去了精度。

我也可以回答你的答案。問題結束時，您說這個數字正用於考慮網絡中數據包的時間戳。現在的問題是：生活期望磨損多久？ 10年？ 10天10秒？以毫秒爲單位的精度失去10位會給你大量的時間與milisecond的精度，我猜做兩包之間的計算是你想要的

來源

2015-02-08 03:39:08 Amadeus

你從哪裏得到「包時間戳」的想法？ OP從未這麼說過。 – 2015-02-08 03:43:29

好吧，他說：「請注意，他們通過網絡發送這個」時間戳「，並仍然用它來計算。」 – Amadeus 2015-02-08 03:44:36

它是安全的存儲毫秒紀元以來UINT32

回答

相關問題