[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <a97511a0b863fd0c36210a6dd331fb89@smtp.hushmail.com>
Date: Sun, 20 Jan 2013 01:25:20 +0100
From: magnum <john.magnum@...hmail.com>
To: john-dev@...ts.openwall.com
Subject: Re: binary_hash_[0-6] and get_hash_[0-6]
On 20 Jan, 2013, at 0:09 , Frank Dittrich <frank_dittrich@...mail.com> wrote:
> The formats currently implemented implement different numbers of hash
> functions.
>
> The following grep commands are not perfect, but I think they provide an
> overview which is good enough:
>
> (unstable-jumbo)src $ grep "binary_hash_[0-6]$" *_fmt*.c|sed
> 's#^.*\(.\)$#\1#'|sort|uniq -c
> 16 4
> 103 6
> (unstable-jumbo)src $ grep "get_hash_[0-6]$" *_fmt*.c|sed
> 's#^.*\(.\)$#\1#'|sort|uniq -c
> 3 0
> 3 1
> 3 2
> 3 3
> 19 4
> 3 5
> 106 6
>
> While certain formats most likely will never be run with a number of
> hashes warranting a get_hash_6 implementation, those which currently
> implement 5 or 6 hash functions might implement the 7th as well.
> Or am I missing something?
You are right. Patches are welcome! BTW I have no idea what happens if the available sizes of get_hash does not match the ones of binary_hash. Your greps seem to indicate we have such cases.
> Another observation:
> Many formats seem to use static copies of the same hash functions.
> Would it make sense to provide useful default functions instead of
> "implementing" N copies?
It would be easy for binary_hash(). For get_hash(), a shared function would not have access to the binaries as they are local to the format. Maybe they could be implemented as macros in formats.h, that expand to real static functions.
magnum
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
