[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <003301cd18e8$18ed0c00$4ac72400$@net>
Date: Thu, 12 Apr 2012 15:08:58 -0500
From: "jfoug" <jfoug@....net>
To: <john-dev@...ts.openwall.com>
Subject: RE: MSCash2 formats reliability & usability
We really 'might' think of using common functions:
valid()
prepare()
split() ???
for common 'sub' formats (i.e. only 1 valid() for any mscash2).
The other functions will likely be specialty written. But the code that
john 'uses' prior to a run (get_salt would NOT fall into this category),
should only have a single function.
Thus, we probably should have mscash_common.c which contains these files
(non-static), and a mscash_common.h. Then mscash2_fmt_plug.c (or any
other), would simply include the header file, and assign the function names
to the proper locations within the format structure.
This 'could' require some of the other functions to be expanded to handle a
wider range of 'valid' candidates, OR to make the valid/prepare set see a
reduced range of valid formats.
Again, this is what you get in 'bleeding edge', and with multiple people
working on different parts. Much of this will shake itself out with time,
and portability issues, or robust issues will get addressed. However, it
can be pretty hard to do this, when one or more sub-formats is heavily under
development.
Jim.
>From: magnum [mailto:john.magnum@...hmail.com]
>
>Great, committed now. Sayantan (and Lukas), you probably want to
>incorporate the same code in your GPU formats too.
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.
