On 11/1/16 10:08 AM, Steven Schveighoffer wrote:
On 10/31/16 3:24 PM, Ali Çehreli wrote:
Because it considers the .ptr property of arrays as well:
[snip]
return bytesHash(bytes.ptr, bytes.length, seed); // <-- HERE
bytesHash shouldn't use the pointer value in any way, it should just use
the pointer to look at the bytes.
And the issue is not there it is simpler than that. Here is the entire
definition of hashOf
(https://github.com/dlang/druntime/blob/master/src/object.d#L3176):
size_t hashOf(T)(auto ref T arg, size_t seed = 0)
{
import core.internal.hash;
return core.internal.hash.hashOf((cast(void*)&arg)[0 .. T.sizeof],
seed);
}
Note that if arg is a string, then it's going to take the hash of the
bytes that define the dynamic array pointer and length. Not at all what
the user is expecting. Would be even more surprising for an object
reference or pointer.
I'm not sure what the bug is here. It's quite possible the intention is
to provide a low-level primitive that avoids all hashing customization.
However, to have it called hashOf, and then have another internal
function called hashOf that does something different, is quite
surprising and error prone. Indeed, I think Ali did not realize where
the definition of hashOf was coming from.
At the very least, the documentation needs updating.
-Steve
