<p dir="ltr">if youd  don't care the readabilit, you can compress the function name....</p>
<div class="gmail_quote">在 2013-6-20 上午7:22，"Sean Silva" <<a href="mailto:silvas@purdue.edu">silvas@purdue.edu</a>>写道：<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Jun 19, 2013 at 3:39 PM, Robinson, Paul <span dir="ltr"><<a href="mailto:Paul_Robinson@playstation.sony.com" target="_blank">Paul_Robinson@playstation.sony.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">> From: <a href="mailto:llvmdev-bounces@cs.uiuc.edu" target="_blank">llvmdev-bounces@cs.uiuc.edu</a> [mailto:<a href="mailto:llvmdev-bounces@cs.uiuc.edu" target="_blank">llvmdev-bounces@cs.uiuc.edu</a>] On Behalf Of Sean Silva<br>


> Sent: Wednesday, June 19, 2013 11:45 AM<br>
> To: edA-qa mort-ora-y<br>
> Cc: <<a href="mailto:llvmdev@cs.uiuc.edu" target="_blank">llvmdev@cs.uiuc.edu</a>><br>
> Subject: Re: [LLVMdev] How to deal with potentially unlimited count/length symbol names?<br>
<div><div>><br>
> On Wed, Jun 19, 2013 at 1:04 AM, edA-qa mort-ora-y <<a href="mailto:eda-qa@disemia.com" target="_blank">eda-qa@disemia.com</a>> wrote:<br>
><br>
> > The problem is that if I derive the name from what the type contains the<br>
> > length of that name is essential unbound. So how does one generate<br>
> > names?  I'm thinking of just using a long hash and hoping I don't get<br>
> > accidental collisions. Surely there must be a better way?<br>
><br>
> Just a cryptographic hash (e.g. SHA1) to avoid the need to "hope" that there are no collisions.<br>
><br>
> -- Sean Silva <br>
<br>
</div></div>Cryptographic hashes don't guarantee you get no accidental collisions;<br>
their goal is to make it super hard to produce a collision _on purpose_.<br>
What you need is an algorithm designed for string inputs, with good<br>
uniformity, and an adequate output size; there are many.<br></blockquote><div><br></div><div>It's obvious by the pigeonhole principle that there must be collisions. The point of my statement that OP doesn't have to "hope" that it avoids collisions: crypto hashes are designed (and depended on across the globe) to make collisions vanishingly unlikely; it's orders of magnitude more likely that a cosmic ray will silently corrupt the hash computation than for two strings to collide (except possibly for maliciously-chosen strings for weaker hashes).</div>

<div><br></div><div>-- Sean Silva </div></div></div></div>
<br>_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a>         <a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
<br></blockquote></div>