[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120716074833.GD20766@openwall.com>
Date: Mon, 16 Jul 2012 11:48:33 +0400
From: Solar Designer <solar@...nwall.com>
To: john-dev@...ts.openwall.com
Subject: Re: New core (?) LM fails alignment
On Sun, Jul 15, 2012 at 08:52:04PM +0200, magnum wrote:
> Merged and committed now. I do not think there were any new merge "hazards".
Thanks!
BTW, you may remove "struct db_password;" from formats.h in bleeding, as
this is a stale line from Jim's revision of the source() interface.
> I'm using this in formats.h:
>
> /*
> * Default alignment (used unless known)
> */
> #ifdef ARCH_ALLOWS_UNALIGNED
> #define DEFAULT_ALIGN MEM_ALIGN_NONE
> #else
> #define DEFAULT_ALIGN MEM_ALIGN_WORD
> #endif
>
> Many formats will probably benefit from using 4 bytes alignment instead
> of MEM_ALIGN_NONE, should we consider using that instead?
Yes, and some will probably benefit from using MEM_ALIGN_WORD.
However, since the formats.c self-test applies this specified alignment
to testing of binary() and salt() return pointers, tests may start
failing if we set the default higher than what the heuristics in
format.c's alloc_binary() previously resulted in. So maybe we should use:
#define DEFAULT_ALIGN(size) \
(((size) >= ARCH_SIZE) ? ARCH_SIZE : ((size) >= 4 ? 4 : 1))
(untested).
Alternatively, we could set it to a magic value like -1 and re-introduce
the above heuristics in code for whenever the magic value is specified.
As to the check for ARCH_ALLOWS_UNALIGNED, we already have it inside
memory.c for the memory saving case, so doing it here might not be a
good idea.
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.
