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.