[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <33f1e66d8d193f07fa4bd5fddc1365db@smtp.hushmail.com>
Date: Thu, 25 Jun 2015 19:03:17 +0200
From: magnum <john.magnum@...hmail.com>
To: john-dev@...ts.openwall.com
Subject: Re: light way to make extensions to format interface
On 2015-06-25 14:24, Aleksey Cherepanov wrote:
> As I understand, any change to format interface means code updates in
> all formats (200+). I propose an idea of solution for easy extending.
Those updates are a great opportunity for collecting sed-fu though ;-)
Given enough regexp tweaking, you can always fix all but a handful.
A simple (non-)solution is to always expand the struct(s) at the tail
and only change formats that need the new stuff. We already do just that
with the test struct's optional 'fields' array.
> In addition to current structure, there may be an optional array with
> pairs: string literal for method name and pointer to method
> implementation. The array is of variable length and finished by NULL,
> just like test vector. So it would be possible for a format to
> announce only implemented methods.
>
> To support that, ./configure should collect such arrays like formats'
> structures. At start, john could repack them into structures like
> formats' structures for easy access (most probably only array of
> chosen format should be repacked).
I have no firm opinion on this. I can't immediately see any real problem
with your idea, but I'm also not overly excited. The problem you are
trying to solve isn't that much of a problem.
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.
