<div dir="ltr"><div><div><div>It is unclear to me whether the problem you wish to solve is provide:<br><br></div><div>- resilient hash functions<br></div><div>- resilient hash containers<br></div><div><br>For the latter another solution, rather than modifying the hash function, would be to modify the hash container.<br>
<br>For example, one could initialize `std::unordered_set` (and co) with a random seed and simply XOR this seed with the result of `h(k)`. Said seed can even change each time the container is rehashed to prevent an observer from analyzing the collisions and cause undue chaining.<br>
</div><br></div>And this would not require a salted hash so there would be no issue with the standard.<br><br></div>-- Matthieu<br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Sat, Aug 31, 2013 at 9:03 PM, Zhihao Yuan <span dir="ltr"><<a href="mailto:zy@miator.net" target="_blank">zy@miator.net</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On Sat, Aug 31, 2013 at 2:37 PM, Howard Hinnant <<a href="mailto:hhinnant@apple.com">hhinnant@apple.com</a>> wrote:<br>

> [hash.requirements]/ Table 26 says:<br>
><br>
>> The value returned shall depend only on the argument k. [ Note: Thus all evaluations of the expression h(k) with the same value for k yield the same result. — end note ]<br>
<br>
</div>I know.  But the wording here is not clear: does that mean two<br>
different standard library implementations have to share the<br>
same hash function?  Obviously not.<br>
<div class="im"><br>
> Now it isn't clear, at least to me, that if this is talking about all evaluation within the process, or across different invocations of the same process, or even across invocations of different processes.  Without guidance from the LWG, I think we need to assume the most conservative answer.<br>

<br>
</div>Tend to agree.<br>
<div class="im"><br>
> I faintly recall this subject was brought up at the Portland meeting, Fall 2012.  I do not believe anything was definitively resolved at that time.  I do not know if this issue was discussed this Spring in Bristol.  I do not see an LWG issue on this subject.<br>

<br>
</div>I guess it's inside<br>
<br>
  <a href="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2012/n3333.html" target="_blank">http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2012/n3333.html</a><br>
<br>
Thanks to the labor day, the deadline is extended.  Can I submit<br>
an issue like<br>
<br>
"The value returned shall depend only on the argument k<ins> for<br>
the duration of the program</ins>  [ Note: Thus all evaluations of the<br>
<div class="im">expression h(k) with the same value for k yield the same result<br>
</div><ins> for each execution of the program(, some guideline here?)</ins>.<br>
— end note ]"<br>
<br>
The hashing can't be per-process BTW.  First the standard knows<br>
nothing about OS process; second, practically that makes you unable<br>
to share an unordered container to a child process :(<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Zhihao Yuan, ID lichray<br>
The best way to predict the future is to invent it.<br>
___________________________________________________<br>
4BSD -- <a href="http://4bsd.biz/" target="_blank">http://4bsd.biz/</a><br>
</font></span><div class="HOEnZb"><div class="h5"><br>
_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@cs.uiuc.edu">cfe-dev@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev</a><br>
</div></div></blockquote></div><br></div>