[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: sort --random-sort

From: Jim Meyering
Subject: Re: sort --random-sort
Date: Wed, 30 Nov 2005 11:55:29 +0100

Frederik Eaton <address@hidden> wrote:
> On Tue, Nov 29, 2005 at 07:31:45AM +0100, Jim Meyering wrote:
>> Frederik Eaton <address@hidden> wrote:
>> >> Maybe we need an option to trade off speed for quality,
>> >> if it makes such a big difference.
>> >
>> > Hmm. Maybe there will be a difference. Well, why don't I make
>> > ISAAC_LOG or ISAAC_WORDS part of isaac_state so that shred and sort
>> > can use different values? I don't think it will be important for
>> > 'sort' to use a very strong hash, since crackers only have the order
>> > of the hash values to go by, and not the values themselves.
>> This seems like a very good point.
>> How about having this in rand-isaac.h:
>> #ifndef ISAAC_LOG
>> # define ISAAC_LOG 8
>> #endif
>> then define ISAAC_LOG to 3 just before including it from sort.c?
> Then I would also have to include rand-isaac.c in sort.c, since
> rand-isaac.c itself includes rand-isaac.h, and is normally compiled
> separately. What's wrong with making it a parameter of the state
> structure?

If it's compiled separately with a variable state array size,
then the state array will have to be allocated from the heap and
freed when done.  Or you could avoid using the heap at the expense
of limiting the size to some fixed maximum.  That would make this
code more like random(3).

It's probably not worth much more effort to make the code
stand-alone, since we'll probably remove it from shred -- then
sort will be the only client.  Considering that, it might be best
to simply include the .c file.  Either approach is fine with me.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]