Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 23 Sep 2014 01:01:07 +0200
From: magnum <>
Subject: Re: Workaround for option flags shortage

On 2014-09-22 11:14, Solar Designer wrote:
> On Mon, Sep 22, 2014 at 12:42:13AM +0200, magnum wrote:
>> 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.

I had the idea I could just verify that the buffer pointer was NULL but 
that was not the case when a 'format' was used with sscanf(). So I ended 
up adding a flag to the opt_entry struct. This made for a trivial patch 
that should hopefully not fail or cause any problems (yeah famous last 

After the above commit, another one uses this logic to free 15 option 
flags in the high/jumbo 32 bits. Pretty good ROI for effectively 2-3 
lines of code :-)


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.