search for: sha128

...t;>> >>> or maybe: >>> >>> virtual llvm::hash_code contentHash() const = 0 >>> >> We could use a crypto hash too with the function prototype that looks > like :- > > virtual lld::crypto::sha256 contentHash() const = 0 I'd use SHA128 or MD5 as the linker does not handle hostile input. I think as long as it's collision free, it should suffice. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130509/9ff353fa/attachment.html>

On Wed, May 8, 2013 at 6:03 PM, Rui Ueyama <ruiu at google.com> wrote: > I'd use SHA128 or MD5 as the linker does not handle hostile input. I think > as long as it's collision free, it should suffice. FWIW, the need for a collision free hash -- or *digest*, my preferred term -- is well known. Interestingly newer, supposedly "more secure" digest algorithms are also...

On 5/8/2013 12:38 AM, Michael Spencer wrote: > On Tue, May 7, 2013 at 10:08 PM, Nick Kledzik <kledzik at apple.com> wrote: > >> Shankar, >> >> Do you mean add a method like: >> >> virtual unsigned contentHash() const = 0; >> >> or maybe: >> >> virtual llvm::hash_code contentHash() const = 0 We could use a crypto hash too

On Tue, May 7, 2013 at 10:08 PM, Nick Kledzik <kledzik at apple.com> wrote: > Shankar, > > Do you mean add a method like: > > virtual unsigned contentHash() const = 0; > > or maybe: > > virtual llvm::hash_code contentHash() const = 0 > > to lld::DefinedAtom? That seems good to me. We just need to figure out > what should happen with atoms not