Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 22 Sep 2014 13:14:19 +0400
From: Solar Designer <solar@...nwall.com>
To: john-dev@...ts.openwall.com
Subject: Re: Workaround for option flags shortage

magnum -

On Mon, Sep 22, 2014 at 12:42:13AM +0200, magnum wrote:
> Despite the fact Jumbo use a 64-bit field for options flags, we are 
> again out of them since long ago (well there are spare flags in the 
> lower 32 bits but we have refrained from using them in Jumbo).

Ouch.  BTW, I am annoyed I can't use -i for incremental mode anymore,
having to type -inc or the like.

> Unless you have a better idea, I plan the following workaround:
> For options that require an argument, add some trivial logic in getopt.c 
> (or whatever is proper) that verifies the argument was not already set. 
> If it was, handle it as a dupe option.
> 
> This means simple options like
> 
> 	{"mkpc", FLG_MKPC, FLG_MKPC, 0, OPT_REQ_PARAM,
> 		"%u", &options.force_maxkeys},
> 
> can be just
> 
> 	{"mkpc", FLG_NONE, 0, 0, OPT_REQ_PARAM,
> 		"%u", &options.force_maxkeys},
> 
> and get the same protection without need of its own flag. I think this 
> will work just fine, and it would free up several handfulls of flags.
> 
> For future support for eg. multiple rules or wordlists, like "-wo:1.txt 
> -wo:2.txt", I suppose we should make this new logic active only for the 
> FLG_NONE case. Other than that, I see no caveats. But I haven't actually 
> looked at the code yet.

Your suggested workaround sounds fine to me.

Thanks for bringing this up!

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.