[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <0e31cb3b183504dcd59495f514db4c48@smtp.hushmail.com>
Date: Sun, 15 Jul 2012 20:52:04 +0200
From: magnum <john.magnum@...hmail.com>
To: john-dev@...ts.openwall.com
Subject: Re: New core (?) LM fails alignment
On 2012-07-15 14:55, Solar Designer wrote:
> On Sun, Jul 15, 2012 at 01:49:33PM +0200, magnum wrote:
>> On 2012-07-15 12:57, Solar Designer wrote:
>>> I decided not to do that yet. Instead, I made the alignment of binary
>>> and salt configurable per format, which is desirable anyway. While at
>>> it, I also revised the memory.c code not to assume that pointers fit in
>>> "unsigned long", although that assumption caused no trouble so far.
>>
>> I have no objections to that patch other than I will not likely have
>> time to merge it within 8-9 days or so, as I'll have to "investigate"
>> each format while adding this.
>
> I thought that you could start by putting safe placeholder values in
> there - e.g., ARCH_SIZE for all alignments unless it is obvious that
> smaller would do. Better yet, we can put in an include file:
>
> #define DEFAULT_ALIGN ARCH_SIZE
>
> and use that. Then it'd be easy for us to grep for DEFAULT_ALIGN and
> review/replace all those with whatever the format actually requires -
> when we have time for that.
Merged and committed now. I do not think there were any new merge "hazards".
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?
I set Tavis' binary alignment to MEM_ALIGN_SIMD, for everything else I
used DEFAULT_ALIGN for now.
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.
