Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Fri, 18 Sep 2015 20:07:59 +0300
From: Solar Designer <solar@...nwall.com>
To: john-dev@...ts.openwall.com
Subject: Re: larger bitmaps and hash tables

On Fri, Sep 18, 2015 at 06:54:41PM +0200, magnum wrote:
> On 2015-09-16 19:44, Solar Designer wrote:
> >This last one might be related to the "while (--size >= 0);", which no
> >longer stops the loop when size was already 0.  It might be a real bug
> >that would show up if we set PASSWORD_HASH_SIZE_FOR_LDR lower.
> 
> It was worse than that, it was definitely a bug. I'm surprised it worked 
> at all. I committed a fix separating the signed int used for the loop 
> from the size_t used for the alloc.

Yeah, I posted a similar patch in here:

http://www.openwall.com/lists/john-dev/2015/09/18/15

Yours is shorter due to it renaming the other use of the previously
reused variable.

> BTW in case we start using mem_calloc we won't need that size_t at all, 
> we'd just do
> 
> 	db->password_hash = mem_calloc(password_hash_sizes[size],
> 	    sizeof(struct db_password *));

Sure.  I had it that way in the tree where I observed fork() slowdown.
(And some other memset()'s were changed as well.)

Alexander

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.