[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <024601cd5525$e8568e70$b903ab50$@net>
Date: Thu, 28 Jun 2012 07:02:35 -0500
From: "jfoug" <jfoug@....net>
To: <john-dev@...ts.openwall.com>
Subject: RE: Is saving 2 bytes per salt worth the effort?
>From: Frank Dittrich [mailto:frank_dittrich@...mail.com]
>>> --- a/src/episerver_fmt_plug.c
>>> +++ b/src/episerver_fmt_plug.c
>>> @@ -76,7 +76,7 @@ static ARCH_WORD_32 (*crypt_out)[BINARY_SIZE /
>>> sizeof(ARCH_WORD_32)];
>>>
>>> static struct custom_salt {
>>> int version;
>>
>> "int version" can be changes to "char version". Even more savings!
>
>That was my second idea:
Changing int to char will save no space, on most compilers. This is in a
structure, and most will align all structure members on a natural word
boundary (int).
Thus if you changed the above structure, the compiler will do this (behind
the scene)
struct custom_salt {
char version;
char hidden_padding[sizeof(int)-1];
....
Some CPU's (and compilers) will allow structures to be packed, meaning that
a char element like above takes up only the 1 byte. Not all CPU allow this,
and many have a performance hit when you do. The performance hit is why
compilers align the structs, on systems which do allow unaligned memory
reads.
Just an FYI when thinking about pinhole tweaks like this. Many
'optimizations' like this will gain absolutely nothing, and can cause other
problems.
Jim.
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.
