Comment #0 by verylonglogin.reg — 2016-12-15T15:21:06Z
In our root `object` module we have a function `hashOf` [1] which accept any type as the first parameter and optional seed as the second parameter.
This function signature is error-prone because its signature allows this incorrect usage:
---
hashOf(arr.ptr, arr.length); // hash of ptr with seed set to length
---
It's a major issue as (ptr, length) usage pattern is common in programming and incorrect hash function behavior is hard to debug.
[1] http://dlang.org/phobos/object.html#.hashOf
Comment #1 by verylonglogin.reg — 2016-12-15T16:27:49Z
This issue caused druntime Issue 16974.
Comment #2 by verylonglogin.reg — 2016-12-15T16:45:03Z
A possible solution is to require explicit second argument type specification.
Using current language abilities it can be done with helper `seed` function or struct:
---
hashOf(obj, seed(0));
---
or with function overload rename:
---
hashOfWithSeed(obj, 0);
---
Comment #3 by safety0ff.bugz — 2016-12-16T01:56:14Z
(In reply to Denis Shelomovskii from comment #1)
> This issue caused druntime Issue 16974.
Druntime used to have a function rt.util.hash.hashOf with signature:
size_t hashOf( const(void)* buf, size_t len, size_t seed )
Which made up most references to 'hashOf' within druntime (by TypeInfos.)
I wouldn't be surprised if this bug was due to thinking it's calling rt.util.hash.hashOf instead of object.hashOf.
Mistaking core.internal.hash.hashOf for rt.util.hash.hashOf was responsible for a recent regression.
Comment #4 by verylonglogin.reg — 2016-12-17T06:41:36Z
(In reply to safety0ff.bugz from comment #3)
> (In reply to Denis Shelomovskii from comment #1)
> > This issue caused druntime Issue 16974.
>
> Druntime used to have a function rt.util.hash.hashOf with signature:
> size_t hashOf( const(void)* buf, size_t len, size_t seed )
>
> Which made up most references to 'hashOf' within druntime (by TypeInfos.)
>
> I wouldn't be surprised if this bug was due to thinking it's calling
> rt.util.hash.hashOf instead of object.hashOf.
>
> Mistaking core.internal.hash.hashOf for rt.util.hash.hashOf was responsible
> for a recent regression.
No doubts it's a function call from wrong module. But it doesn't change the fact that Issue 16974 is caused by this issue.
Comment #5 by schveiguy — 2023-10-08T14:40:58Z
I would recommend this be closed as WONTFIX.
If you don't follow the specification of the function, I don't see how you expect to get correct results.
Comment #6 by robert.schadek — 2024-12-07T13:37:10Z