You Can't Always Hash Pointers in C (2016)

Slightly related (but only slightly), on the PS2 (games console, from Sony) you could access main memory with three different pointers, cacheable, uncached accelerated and uncached (which was the same base address with different high bits set accordingly). Each mode had reasons to be used (for example, when you read&#x2F;write to memory which is cacheable and then fire off a DMA transfer, the data being transferred may, and often won&#x27;t, match, what has been set in the program, until a cache flush has been requested). As you can imagine, this regularly resulted in hard to track down bugs.<p>Anyway, the bottom line of this is: I have seen various pieces of code on platforms which when comparing a memory pointer you need to mask out several bits (unless of course you actually want to differentiate between the different access methods of the same piece of memory).<p>It isn&#x27;t quite what this article is talking about, but I thought it was a related piece of interesting trivia to those that don&#x27;t already know ;)

One thing interesting to note is that C++ has a specialization for<p>template&lt;class T&gt; struct hash&lt;T<i>&gt;<p>which is required to have the correct semantics.<p>Given that the in practice the underlying machine models of C and C++ are very similar, and that the most widely used C compilers (gcc, clang, msvc) are also C++ compilers, in practice hashing C pointers is likely not an issue.<p>However, if you want to hash pointers in a way that is blessed by the standard, you can probably do this<p>my_hash.cc<p><pre><code> #include &lt;functional&gt; extern &quot;C&quot;{ size_t hash(char* c){ std::hash&lt;char*&gt; hasher; return hasher(c); } } </code></pre> my_hash.h<p><pre><code> size_t hash(char* c); </code></pre> EDIT: Added code if you wanted to be pedantic about it.<p>Then you just link your C program to my_hash.o and include my_hash.h

Discussed at the time: <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=11805030" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=11805030</a>

Generally, hashing pointers in C or C++ is a bad idea anyway.<p>Unless, you have a particular love for debugging non-reproducible behavior that is.

With Microsoft going to &quot;fat pointers&quot; in their systems, some pointer conversions are not going to work.

I don&#x27;t like this genre of programming blog post. These things always amount to premature optimization for portability. They point out that some technique that&#x27;s been used by millions of programs for decades might not work on every single architecture that&#x27;s technically compatible with the C standard. So what? The techniques work, and because so many programs use these techniques, they&#x27;ll <i>keep</i> working.<p>In practice, almost nobody targets esoteric environments. Avoiding useful and well-known tools just for the sake of an environment that will never see your program is just a needless self-imposed tax that&#x27;s going to suck time from other aspects of development. In my programs, I&#x27;ll keep hashing uintprt_t values.

Why would one need to hash pointers? Seems like a bad idea and data strutures made of pointers like trees are pretty well behaved.