[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <5a0b35cca37459662d90350ca89e4f36@smtp.hushmail.com>
Date: Mon, 22 Sep 2014 00:42:13 +0200
From: magnum <john.magnum@...hmail.com>
To: john-dev@...ts.openwall.com
Subject: Workaround for option flags shortage
Solar,
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).
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.
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.
