[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4DDA72A1.40009@bredband.net>
Date: Mon, 23 May 2011 16:43:45 +0200
From: magnum <rawsmooth@...dband.net>
To: john-dev@...ts.openwall.com
Subject: Re: Ideas for jumbo-6
On 2011-05-23 15:29, JFoug wrote:
> for #3
>
> Which ever method is chosen, the core formats declares would be in
> john.c and then a #include fmt_externs.h and the core formats
> init_one() calls would be in john.c with #include "fmt_registers.h" in
> the middle of them. All other extern stuff or init stuff would be removed.
>
> *******************
> for #4
>
> This goes along with #3. The POC designed, only worked with the
> *_plugfmt.c (thus, that is likely going to be a factor in choosing for
> #3). This is very simple. There is a build rule done, that finds all
> of the wildcard *_plugfmt.c files.
Sooner or later we will probably have to handle plugformat collisions so
we might as well give it a thought now. What if a user has foo_plugfmt.c
and bar_plugfmt.c but both formats declare its struct as "fmt_sha2"
and/or a params.label of "sha-2"?
1. It's not detected, so the build will fail with cryptic errors.
2. The pre-build script bails out with a helpful error.
3. The pre-build script emits a warning, but solves the problem by
chosing one of them using whatever heuristics - like "prefer thin over
thick" and "prefer new over old (file timestamp)".
We should strive to keep this as simple as possible though so I guess
number 2 is the way to go. But just maybe we could want that
thin-over-thick thing hacked in? Not that I know how we would tell them
apart in a canonical way.
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.
