Re: Good hash for pointers

On 24/05/2024 02:28, Malcolm McLean wrote:

On 24/05/2024 00:52, Tim Rentsch wrote:

Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>

On 23/05/2024 23:49, Tim Rentsch wrote:
>

Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>

What is a good hash function for pointers to use in portable
ANSI C?

>
I have a preliminary question.  Do you really mean ANSI C, or
is C99 acceptable?

>
C89 is better.
But the pass has been sold.

>
I'm not asking which you think is better.  I'm asking about
what your requirements are.

 C 89.
I don't want to pull in C99 types and so on just for a hash function.
 

Tim is right that the <stdint.h> types are /vastly/ better for this sort of thing.  And you won't find any C89/C90 compilers that don't support <stdint.h> even in C89/C90 mode.  You might choose to avoid other C99 features, in case you have any users that insist on C89/C90, but you can't get anywhere with just the standard C89/C90 types.  On a platform such as 64-bit Windows, pointers are 64-bit but the biggest C89/C90 integer type is "unsigned long", which is 32-bit on that platform.  You can't get at the upper bits of the pointer without compiler-specific extensions - and if you allow extensions, you might as well allow <stdint.h> and make life far simpler for everyone.
If you insist on using C89/C90, make sure that the code is compatible (with the same semantics) for more modern standards.  There are few fanatics left who think C89/C90 is "better" than C99 or newer standards, so the majority of potential users will want C99, C11, or - perhaps most likely - a compiler-specific variation of one of these.  It would be a shame if your code relied on pre-C99 integer promotion rules, or used implicit int, or had identifiers that conflict with newer standards. These would undoubtedly be far worse for users than any purely imagined problems caused by #include <stdint.h>.
(As a pedantic quibble, I believe ANSI invariably re-publish ISO C standards as updated ANSI C standards.  So "ANSI C" currently refers to C17.  It is best, IMHO, to explicitly say C89 and/or C90 rather than "ANSI C".)