[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <90700bd8e1ecc45de90fadc4f06bb8d9@smtp.hushmail.com>
Date: Thu, 30 Jan 2014 10:31:57 +0100
From: magnum <john.magnum@...hmail.com>
To: john-dev@...ts.openwall.com
Subject: Re: Handling of hashes with different iteration counts
On 2014-01-30 02:33, Frank Dittrich wrote:
> On 01/29/2014 10:10 PM, magnum wrote:
>> On 2014-01-29 21:31, Frank Dittrich wrote:
>>> Defining an array of functions is one way to do it.
>>> Defining a single function with one more parameter (id of tunable cost)
>>> is another one.
>>
>> Another one is a single function that returns [a pointer to] an array of
>> uint: If you don't have any notion of variable cost, the array is {0} or
>> perhaps the pointer is NULL. If you have it, array can be {iter, 0} or
>> {t_cost, m_cost, 0} and so on with virtually no limit.
>
> And then one of the formats decides to return an array of a different
> size than usual, under rare, hard to reproduce circumstances?
What?! How is this a problem with what I suggested?
> No, thanks. I really don't want to think about such situations.
> If a format method is either NULL or returns a single unsigned int
> value, that's easy to handle. The worst case that can happen is I report
> bogus differences if a format is seriously broken.
How is my suggestion different in this regard? I really don't understand
your concern. It's a null-terminated array, no more crazy and wild than
a null-terminated string. It's totally flexible - you will support a
size up to FMT_TUNABLE_COSTS and whenever you bump that figure in
formats.h, no formats need any change except the very one that called
for the increase.
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.
