[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sat, 27 Aug 2011 17:51:17 +0400
From: Solar Designer <solar@...nwall.com>
To: john-dev@...ts.openwall.com
Subject: Re: #include "john.conf2" (a wish list item)
Jim - thank you for working on this!
Some comments are below:
On Fri, Aug 26, 2011 at 04:49:13PM -0500, JimF wrote:
> From: "Lukas Odzioba" <lukas.odzioba@...il.com>
> >Does it really eliminates cycles in include graph? I don't know the
> >code but is it ok when john.conf includes john.conf, and even with
> >recursion level restricion will be processed four times? Maybe it
> >would be better to just have table of processed filenames, and before
> >processing next included file seek it in table. This way we don't care
> >about recursion level.
>
> It certainly 'could' be done that way, but there is quite a bit more code,
> and I am not sure what gain there is.
>
> Here is the totality of code to check recusion levels.
>
> int recurse;
>
> in load_line when processing a line, a new 'include' is detected.
>
> if (recurse > 4) exit fprintf("boom, you lose\n");
> ++recurse;
> cfg_init(new_file_name);
> --recurse;
>
> Then within cfg_init()
>
> if (cfg_data && !recurse) return;
> while (getnextline) load_line()
I think JimF's code is fine for jumbo (although I am relying on what was
said in here; I haven't tried the feature out yet), but just to provide
inspiration for possible enhancements (if we ever choose to implement
those), here are two other pieces of code with detection of infinite
recursion (loop).
The below commit shows a trivial algorithm to detect arbitrary loops
without having to store the entire set of previously seen entries (only
one "seen" entry is kept at a time):
http://cvsweb.openwall.com/cgi/cvsweb.cgi/projects/blists/mailbox.c.diff?r1=1.11;r2=1.12
...whereas the one below actually stores all entries, but in a somewhat
smart way - they're kept on the stack of the recursive calls (so there's
no explicit memory allocation/freeing), yet also added to a linked list:
http://cvsweb.openwall.com/cgi/cvsweb.cgi/Owl/packages/passwdqc/passwdqc/passwdqc_load.c
Also, st_dev/st_ino pairs are stored and compared, rather than filenames.
This avoids having to allocate memory for anything that is not of fixed
size. The drawback is that this is Unix-specific.
Thanks again,
Alexander
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.
