[LLVMdev] How to deal with potentially unlimited count/length symbol names?

罗勇刚(Yonggang Luo) luoyonggang at gmail.com
Wed Jun 19 18:03:26 PDT 2013


if youd  don't care the readabilit, you can compress the function name....
在 2013-6-20 上午7:22,"Sean Silva" <silvas at purdue.edu>写道:

>
>
>
> On Wed, Jun 19, 2013 at 3:39 PM, Robinson, Paul <
> Paul_Robinson at playstation.sony.com> wrote:
>
>> > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu]
>> On Behalf Of Sean Silva
>> > Sent: Wednesday, June 19, 2013 11:45 AM
>> > To: edA-qa mort-ora-y
>> > Cc: <llvmdev at cs.uiuc.edu>
>> > Subject: Re: [LLVMdev] How to deal with potentially unlimited
>> count/length symbol names?
>> >
>> > On Wed, Jun 19, 2013 at 1:04 AM, edA-qa mort-ora-y <eda-qa at disemia.com>
>> wrote:
>> >
>> > > The problem is that if I derive the name from what the type contains
>> the
>> > > length of that name is essential unbound. So how does one generate
>> > > names?  I'm thinking of just using a long hash and hoping I don't get
>> > > accidental collisions. Surely there must be a better way?
>> >
>> > Just a cryptographic hash (e.g. SHA1) to avoid the need to "hope" that
>> there are no collisions.
>> >
>> > -- Sean Silva
>>
>> Cryptographic hashes don't guarantee you get no accidental collisions;
>> their goal is to make it super hard to produce a collision _on purpose_.
>> What you need is an algorithm designed for string inputs, with good
>> uniformity, and an adequate output size; there are many.
>>
>
> 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).
>
> -- Sean Silva
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130620/03991647/attachment.html>


More information about the llvm-dev mailing list