Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!raubtier-asyl.eternal-september.org!.POSTED!not-for-mail From: Bonita Montero Newsgroups: comp.lang.c Subject: Re: Good hash for pointers Date: Sat, 25 May 2024 17:00:11 +0200 Organization: A noiseless patient Spider Lines: 13 Message-ID: References: <86fru6gsqr.fsf@linuxsc.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Date: Sat, 25 May 2024 17:00:10 +0200 (CEST) Injection-Info: raubtier-asyl.eternal-september.org; posting-host="8f6453ced1f3abd55dad14e52b73bf73"; logging-data="3075617"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+wZ5mBYRwP1kwr6NSJYe4XqZp1KkBgToM=" User-Agent: Mozilla Thunderbird Cancel-Lock: sha1:ldRhcfl3Jf3CMIA/I0pjF3i5VKQ= Content-Language: de-DE In-Reply-To: <86fru6gsqr.fsf@linuxsc.com> Bytes: 1694 Am 25.05.2024 um 11:12 schrieb Tim Rentsch: > Your hash function is expensive to compute, moreso even > than the "FNV" function shown earlier. In a case like > this one where the compares are cheap, it's better to > have a dumb-but-fast hash function that might need a > few more looks to find an open slot, because the cost > of looking is so cheap compared to computing the hash > function. A (size_t)pointer * LARGE_PRIME can be sufficient, ignoring the overflow.