DEV Community: Neo Sahadeo

djb2 Hashing is Wrong

Neo Sahadeo — Wed, 21 Oct 2026 07:06:30 +0000

djb2 is a simple hashing algorithm and people keep doing it wrong.

tldr; use this

#define ALPHABET                                       \
  " !\"#$%&'()*+,-./"                                  \
  "0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\\]^_`" \
  "abcdefghijklmnopqrstuvwxyz{|}~"

unsigned long djb2(const char* str) {
  unsigned long hash = 0;
  unsigned char c;

  while ((c = *str++))
    hash = hash * 95u + c;

  return hash;
}

If you've spent time researching hashmaps and generating hashes from strings you would've stumbled across this function:

Which leaves you with two big questions (maybe three), why 5381? why left-bit-shift 5? (and why a bit-shift and not multiplication?). I'm sure Bernstein has his reasons but I couldn't find them.

The Three Issues

The first issue is that 5381 does nothing. Yes, it literally does nothing interesting to the value. I assumed it helps to roll the value over to help distribute it, but if you think about it for a few minutes that doesn't make any sense. Printable ASCII values range from 32 to 127, so the maximum values with the multiplier is between 172 192 to 683 387 (unsigned long values go to 18446744073709551615).

Assuming you picked the maximum printable ASCII value which is "~" your string would need to be 2.7x10^13 characters long to cause an overflow. Any ideas of "seed" go out the window because the hash doesn't present an avalanche effect.

So it's a bust, might as well make it 0.

The second issue is the magical value of 33. Well this is a bit more interesting and also stupid, I'll get to the latter soon. 33 is just magical, I have no clue why it was picked, a few email threads say it produced a better distribution of values (which I'll get into a towards the end).

Decreasing 33 and checking for collisions yields 0% collisions till we reach 25, where it then jumps up to ~3%. Remember that the lowercase alphabet is 26 characters, ASCII lowercase "a" starts at decimal 97 to "z" which is 122. Calculating 122-97 we get drum roll 25. Which starts to make sense why we find duplicates at 25.

The equation above (simplified) is, x * 25 + c. With some collision math we see that "yz" and "za" produce the same hash of 3147. This is because 25 is equal to the largest difference between "a" and "z", which means there will be more than one way to get to a value. Making the value 26 removes collisions as the upper-bound is larger than the difference.

The third issue, why << 5 + hash is just dumb. The main reason I see people say that we should do this is that "bit shifts are faster", and while yes that is true, they're still adding a value to the shifted value which will still be roughly ~2-3 cycles. Not to mention that a modern compiler generates the same optimized code if we just multiplied by 33 face palm.

Here is the Assembly breakdown, the important thing to look at is the right window, line 10 and 11.

sal - shift left
add - add value from x to b

If Optimiser Odis really cared about CPU cycles 32 would be better (only for the lowercase alphabet), that would avoid and extra add and move instruction. So let's just write it in a more human-readable format.

Where are we now?

I've established both 5381 and 33 are random and magical numbers that don't really mean anything. 5381 can be thrown away because seeding a non-avalanching function makes no sense. 33 also has no meaning and writing it as a bit shift does nothing.

If we want a djb2 function that works with all printable ASCII characters with as few collisions as possible we need to pick a value 95. There are 94 typeable characters from a space " " to "~". This leaves us with:

Over 82 317 120 permutations of 4 character string there were 0 collisions.

Final Thoughts

The djb2 most people use doesn't make sense, it doesn't work particularly well and it's more complicated than it needs to be. It doesn't have avalanching nor does 5381 produce fewer collisions. All the reasons I've seen online rationalizing the use of these two numbers still doesn't make much sense.

How to setup tree-sitter highlighters and parsers for Neovim

Neo Sahadeo — Mon, 27 Apr 2026 08:21:13 +0000

If you're reading this, you're probably trying to figure out how to move on after the travesty that was Apr 3, 2026 for nvim-treesitter.

Edit: There is a plugin to manage this process for you, -> Tree Sitter Manager, but if you still want to do it manually read this.

This post will be a walk through on how to setup syntax highlighting for Neovim with tree-sitter.

Prerequisites:

You will need the tree-sitter cli

Setting up Queries

Queries are the languages that contain the .scm files required to tell tree-sitter how to highlight code.

The easiest way to install this is to make the queries directory in you nvim path, e.g. ~/.config/nvim/queries

After which clone the nvim tree-sitter repo and move the queries folder into the nvim/queries dir.

1.1 clone --depth=1 https://github.com/nvim-treesitter/nvim-treesitter

1.2 mv nvim-treesitter/runtime/queries ~/.config/nvim/

That should be that, most syntax should immediately work.
If certain files like .svelte are not working, you can try forcing tree-sitter to start. I'll use an autocommand to attach a callback during file type loads.

~/.config/nvim/init.lua

vim.api.nvim_create_autocmd('FileType', {
    pattern = { 'svelte', 'python', 'javascript', 'typescript', 'typescriptreact', 'rust', 'go', 'c', 'c++' },
    callback = function()
        vim.treesitter.start()
    end,
})

If its still not working, you will have to install your language parser(s). Move on to how to install parsers below.

To read more about the queries read the docs NVIM TREESITTER QUERIES.

Install a Parser

The Neovim docs say that:

Parsers are searched for as parser/{lang}.* in any 'runtimepath' directory.

but I think that's a bit messy so I'll create a tree-sitter directory to install parsers.

2.1 mkdir ~/.local/share/tree-sitter/

Let's install the tsx parser to demonstrate how this process works.

Clone this typescript-treesitter repo into that dir.

2.2 git clone --depth=1 https://github.com/tree-sitter/tree-sitter-typescript ~/.local/share/tree-sitter/tree-sitter-typescript

Next, we need to build everything. You will need the tree-sitter cli. cd into the repo.

2.3.1 make

The output looks similar to this.

Next since this repo contains both the tsx and typescript parser, they to need to be built separately. Since typescript is most likely working, let's build tsx

cd into tsx and run the tree-sitter builder.

2.3.2 tree-sitter build

This will generate a parser.so file. Now the hard part is done and all we have to do is add it to nvim.

2.4.1

First we need to tell nvim about our parser.

~/.config/nvim/init.lua

vim.treesitter.language.add(
    'tsx',
    { path = '/home/neosahadeo/.local/share/tree-sitter/tree-sitter-typescript/tsx/parser.so' }
)

2.4.2

Next we need to tell nvim what highlighter we want to load into the parser.

~/.config/nvim/init.lua

vim.treesitter.language.register('tsx', { 'typescriptreact' })

This says that nvim should associate the tsx parser with the .tsx file. (The file type name is typescriptreact, to get the name just run :echo &filetype).

After this restart neovim and everything should just work.

Hashmap in C

Neo Sahadeo — Tue, 02 Sep 2025 06:25:24 +0000

The full block of code is listed below.

Introduction

This is a short post on how to write a simple hashmap in C. Hashmaps generally have 3 components

Hash array
Hasher function
A data-structure

The hasher function

The purpose of the hasher is to take in an input and generate a fixed-size number.

In our case we will use a corrected djb2 (Dan J. Bernstein) algorithm to hash our values.

long hash(char *str) {
  unsigned long hash = 0;
  int c;

  while ((c = *str++))
    hash = hash * 95u + c;

  return hash;
};

The hash array (table)

We then need to allocate some memory for the array; this can be done however you want.

I went with

void *bucket_array[1024] = {NULL};

A 'bucket' refers to an element within a hashmap, this because the element is another data-structure.

The Data-Structure

An easy to implement data-structure is a linked-list.

typedef struct Node {
  char *key;
  char *data;
  struct Node *next;
} Node;

The add function

Now, we can implement a system to:

hash our value
store it

The code itself is quite self-explanatory. We first get an index value by hashing our string and taking the modulus with the size of our buffer.

Then we check if there is already a value at that index, if no, create a new node, set the data and key and update the index position.
If yes, then scan through the index to see which node matches our key, if we find a match, update that value with our new data.

int add(char *str, char *data, int size, void **buffer) {
  int index = (hash(str) % (long)size);
  if (buffer[index] == NULL) {
    // no bucket exists
    Node *node = malloc(sizeof(Node));
    node->key = str;
    node->data = data;
    buffer[index] = node;
  } else {
    // bucket exists
    Node *linked_list = buffer[index];
    bool exists = false;

    if (strcmp(str, linked_list->key)) {
      exists = true;
    } else {
      while (linked_list->next != NULL) {
        if (strcmp(str, linked_list->key)) {
          exists = true;
        } else {
          linked_list = linked_list->next;
        }
      }
    }
    if (exists) {
      Node *new_node = malloc(sizeof(Node));
      new_node->key = str;
      new_node->data = data;
      linked_list->next = new_node;
    } else {
      linked_list->data = data;
    }
  }
  return index;
}

Code

As for the other functions, I'll leave it as a exercise to the reader.

#include <stdbool.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>

typedef struct Node {
  char *key;
  char *data;
  struct Node *next;
} Node;

Node *head = NULL;
Node *current = NULL;

long hash(char *str) {
  unsigned long hash = 5381;
  int c;

  while ((c = *str++))
    hash = ((hash << 5) + hash) + c;

  return hash;
};

int add(char *str, char *data, int size, void **buffer) {
  int index = (hash(str) % (long)size);
  if (buffer[index] == NULL) {
    // no bucket exists
    Node *node = malloc(sizeof(Node));
    node->key = str;
    node->data = data;
    buffer[index] = node;
  } else {
    // bucket exists
    Node *linked_list = buffer[index];
    bool exists = false;

    if (strcmp(str, linked_list->key)) {
      exists = true;
    } else {
      while (linked_list->next != NULL) {
        if (strcmp(str, linked_list->key)) {
          exists = true;
        } else {
          linked_list = linked_list->next;
        }
      }
    }
    if (exists) {
      Node *new_node = malloc(sizeof(Node));
      new_node->key = str;
      new_node->data = data;
      linked_list->next = new_node;
    } else {
      linked_list->data = data;
    }
  }
  return index;
}

int main(void) {
  // create buckets
  void *bucket_array[1024] = {NULL};

  int x = add("Neo", "bing-bong", 1024, bucket_array);
  printf("%s\n", ((Node *)bucket_array[x])->data);
  add("Neo", "ching-chong", 1024, bucket_array);
  printf("%s\n", ((Node *)bucket_array[x])->data);
  add("Neo", "ding-dong", 1024, bucket_array);
  printf("%s\n", ((Node *)bucket_array[x])->data);

  return 0;
};

Fix missing headerfile in Neovim clangd lsp

Neo Sahadeo — Mon, 12 May 2025 00:48:24 +0000

This is an updated version from the legacy journal that will hopefully help you solve the problem shown below [screenshot]

The following assumes you're using clangd as the LSP server and have already installed GTK.

A missing header file usually means that the LSP does not know the path of the file(s). This can be fixed using pkg-config to get the paths needed to allow the LSP to work correctly.

Run `pkg-config --cflags gtk[n]`

The above command will create long list of includes that you should copy. Replace n with your GTK version, for example, I have gtk4 installed so I would run pkg-config --cflags gtk4

Create a .clangd file

This will be the file the clangd LSP will use to resolve paths. Paste the code in and format it to look like below (you're paths will be different to mine). If you're using Vim here are the commands to quickly do this %s/ /\r/g and %s/\(.*\)/"\1",/g

CompileFlags:
    Add: [
        "-I/usr/include/gtk-4.0",
        "-I/usr/include/pango-1.0",
        "-I/usr/include/fribidi",
        "-I/usr/include/harfbuzz",
        "-I/usr/include/gdk-pixbuf-2.0",
        "-I/usr/include/cairo",
        "-I/usr/include/freetype2",
        "-I/usr/include/libpng16",
        "-I/usr/include/pixman-1",
        "-I/usr/include/graphene-1.0",
        "-I/usr/lib/graphene-1.0/include",
        "-mfpmath=sse",
        "-msse",
        "-msse2",
        "-I/usr/include/glib-2.0",
        "-I/usr/lib/glib-2.0/include",
        "-I/usr/include/libmount",
        "-I/usr/include/blkid",
        "-I/usr/include/sysprof-6",
        "-pthread"
    ]

Restart your editor / LSP

After creating the file your LSP should recognize the GTK header file.

Salting & Hashing🍳

Neo Sahadeo — Thu, 11 Jul 2024 13:07:32 +0000

What is salting 🧂?

Salting is the process of adding data into a value before hashing.

What is hashing #️⃣?

Hashing is the process of converting data into a fixed-length string.

fixed-length: all hashes will have the same length

⚠️Something important to highlight is that hashing is not encrypting; Hashing or encryption depends on what the ultimate goal of that obfuscation is (orginisation regulations are a factor).

Here's an example:

User 1

(~🐧): echo password | sha256sum
6b3a55e0261b0304143f805a24924d0c1c44524821305f31d9277843b8a10f4e>

User 2

(~🐧): echo password | sha256sum
6b3a55e0261b0304143f805a24924d0c1c44524821305f31d9277843b8a10f4e>

The hashed passwords are identical; and that makes sense, they're the same password passed through the same algorithm. The problem arises when two separate users have the same hashed password and a bad actor gets a hold of these password and they can draw similarities.

Hypothetical scenario of compromised data:

User 1 uses the same password for every-site (not an uncommon thing). One of the sites gets their user-data leaked (also not an uncommon thing) which happens to have User 1's raw password stored. Then another site gets leaked that has User 1 and User 2's passwords that are hashed (but not salted). It's as easy as running a grep search and comparing hashes.

Adding a random SALT:

User 1

(~🐧): echo 01anv3password | sha256sum
afe1f6368ce0f7400ee266d52908e190e64779f2f91f4824ea8f1e595fe76ae1

User 2

(~🐧): echo aKdu4ppassword | sha256sum
a0c787128946d0319fbbbd41312a37c274d7dee345bfad74fca4c670c1bcfea5

From above, adding a random six character SALT changes the hash completely.

Conclusion

Salting is the process of adding data into a value before hashing it
Salts should be random
Hashing is converting data into a fixed-length string
Hashing is not the same thing as encryption

[🐧N.S]

Demo post

Neo Sahadeo — Wed, 03 Jul 2024 19:51:38 +0000

please no reading

DEV Community: Neo Sahadeo

djb2 Hashing is Wrong

The Three Issues

Where are we now?

Final Thoughts

How to setup tree-sitter highlighters and parsers for Neovim

Setting up Queries

Install a Parser

Hashmap in C

Introduction

The hasher function

The hash array (table)

The Data-Structure

The add function

Code

Fix missing headerfile in Neovim clangd lsp

Run pkg-config --cflags gtk[n]

Create a .clangd file

Restart your editor / LSP

Salting & Hashing🍳

What is salting 🧂?

What is hashing #️⃣?

Here's an example:

Hypothetical scenario of compromised data:

Adding a random SALT:

Conclusion

Demo post

Run `pkg-config --cflags gtk[n]`