这是东京内阁的错误吗?

发布于 2024-12-10 19:12:13 字数 922 浏览 1 评论 0原文

它基本上是一个二叉树,它首先搜索哈希来决定它是还是

if(hash > rec.hash){
  off = rec.left;
  entoff = rec.off + (sizeof(uint8_t) + sizeof(uint8_t));
} else if(hash < rec.hash){
  off = rec.right;
  entoff = rec.off + (sizeof(uint8_t) + sizeof(uint8_t)) +
    (hdb->ba64 ? sizeof(uint64_t) : sizeof(uint32_t));
} else {
  if(!rec.kbuf && !tchdbreadrecbody(hdb, &rec)) return false;
  int kcmp = tcreckeycmp(kbuf, ksiz, rec.kbuf, rec.ksiz);
  if(kcmp > 0){
    off = rec.left;
    ...
  } else if(kcmp < 0){
    off = rec.right;
    ...

这是哈希的计算方式:

static uint64_t tchdbbidx(TCHDB *hdb, const char *kbuf, int ksiz, uint8_t *hp){
  ...
  uint32_t hash = 751;
  const char *rp = kbuf + ksiz;
  while(ksiz--){
    ...
    hash = (hash * 31) ^ *(uint8_t *)--rp;
  }
  *hp = hash;
  ...
}

但似乎计算哈希的方式不能确保键的顺序,

这是一个错误吗?

It's basically a binary tree which first searches against hash to decide whether it's left or right:

if(hash > rec.hash){
  off = rec.left;
  entoff = rec.off + (sizeof(uint8_t) + sizeof(uint8_t));
} else if(hash < rec.hash){
  off = rec.right;
  entoff = rec.off + (sizeof(uint8_t) + sizeof(uint8_t)) +
    (hdb->ba64 ? sizeof(uint64_t) : sizeof(uint32_t));
} else {
  if(!rec.kbuf && !tchdbreadrecbody(hdb, &rec)) return false;
  int kcmp = tcreckeycmp(kbuf, ksiz, rec.kbuf, rec.ksiz);
  if(kcmp > 0){
    off = rec.left;
    ...
  } else if(kcmp < 0){
    off = rec.right;
    ...

Here's how hash calculated:

static uint64_t tchdbbidx(TCHDB *hdb, const char *kbuf, int ksiz, uint8_t *hp){
  ...
  uint32_t hash = 751;
  const char *rp = kbuf + ksiz;
  while(ksiz--){
    ...
    hash = (hash * 31) ^ *(uint8_t *)--rp;
  }
  *hp = hash;
  ...
}

But it seems the way the hash calculated can't ensure the orderness of keys,

is it a bug?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

べ繥欢鉨o。 2024-12-17 19:12:13

它不会尝试按键本身的值对键进行排序。它首先按哈希对它们进行排序,然后在哈希冲突的情况下按键值对它们进行排序。

所以不,这不是一个错误。除非您可以引用文档说明这种类型的表按键值排序。

It's not trying to order the keys by the value of the keys themselves. It's ordering them first by hash, and then by key value in the case of a hash collision.

So no, it is not a bug. Unless you can cite documentation saying that this type of table orders by key value.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文