【问题标题】:questions related to source code of PHP uniqid() [closed]与 PHP uniqid() 源代码相关的问题 [关闭]
【发布时间】:2015-06-02 18:32:35
【问题描述】:

在 PHP 源代码函数 uniqid() 中有以下 C 代码: (我删除了一些类型以缩短它)

//...
struct timeval tv;
gettimeofday(&tv, NULL);
int sec  = (int) tv.tv_sec;
int usec = (int) (tv.tv_usec % 0x100000);

// The max value usec can have is 0xF423F,
// so we use only five hex digits for usecs.
printf("%08x%05x", sec, usec);
//...

如果我们抛开批评,他们会尝试生成 64 位时间戳。

0xF423F 可能是 CLOCKS_PER_SEC - 1(CLOCKS_PER_SEC 是十进制的 1000000),

但是这个 0x100000 来自哪里,使用模数而不是按位与的原因是什么?

【问题讨论】:

  • 你的问题只有写代码的人才能真正回答,其他人只能猜测原因
  • 我不同意你的看法。代码并不难解释,但我对毫秒性质的计算缺乏很好的理解。
  • what could be the reason 除了作者本人之外,除了猜测之外,无法回答任何问题
  • 天哪,这段代码太糟糕了

标签: php c unique-id gettimeofday timeval


【解决方案1】:

她或他可以将唯一 ID 写为printf("%08x%08x", sec, usec)

sample output:
55189926000eb16f
5518997900051219
5518997a0005171b

位置 8 到 10 的零是一致的,它们不会增加熵,所以他想摆脱那些零。具有相同熵的新 UID 将短 3 个字节。他可以简单地使用printf("%08x%05x", sec, usec);

sample output:
55189926eb16f
5518997951219
5518997a5171b

但这是假设 usec 保证小于 0x100000 ,否则 UID 将长达 16 个字节。您需要% 0x100000 进行保险。它也与& 0xFFFFF 相同。从技术上讲,保险应该是% 1000000 (decimal),但这并不重要,它仍然是相同的熵。

或者我们可以只使用 16 字节的版本,因为现在节省 3 个糟糕的字节已经无关紧要了。

【讨论】:

  • @LightnessRacesinOrbit 他的 :) 在统计上是正确的。
  • 这并不是真正令人印象深刻的代码,谁为它赢得了赞誉并不重要。
  • @BarmakShemirani: 没抓住重点。并滥用逗号。
  • @LightnessRacesinOrbit:你只是假设我是个男人吗?我的名字没有透露任何信息。
  • @BarmakShemirani:我不在乎你是什么性别。你的性别无关紧要。但是您毫无理由地假设代码作者是男性。
猜你喜欢
  • 1970-01-01
  • 2015-10-19
  • 2013-05-04
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2022-11-28
  • 2012-04-16
  • 1970-01-01
相关资源
最近更新 更多