[JonChesterfield]

I chased that rabbit hole briefly and it's not very clear that the hashed value is required to be <= UINT32_MAX. Closest is a claim by the same author as this post:

> It seems obvious that on 32-bit and 64-bit systems, the function should not give different results

and a commit to mask off the low bits in an implementation elsewhere.

Well, maybe that would be convenient, but overall it seems unimportant. It's necessary for the tool writing the table and the tool reading it to agree but cross compilation is absolutely full of hazards like this anyway.

The code looks fine to me for what that's worth. I can see the assignment in the if being contentious.

[sltkr]

The behavior is obviously an oversight. I'd bet 1 to 10 that if you chased down the original author he would agree.

No sensible engineer would design a hash function that populates the lower 28 bits of the hash code, ALWAYS leaves bits 28 through 31 clear, and then SOMETIMES sets bit 32, but only rarely and only on certain architectures.

It makes no sense as a conscious design. The logical conclusion is that the intent was to create a 28-bit hash function, and the fact that the provided code sometimes sets bit 32 is clearly a bug.

[dahfizz]

It looks like the ELF standard itself says the hash table uses 32 bit values:

> A hash table of Elf32_Word objects supports symbol table access.

https://refspecs.linuxfoundation.org/elf/gabi4+/ch5.dynamic....