[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <04b101cc7940$8e3f4240$aabdc6c0$@net>
Date: Thu, 22 Sep 2011 10:59:01 -0500
From: "jfoug" <jfoug@....net>
To: <john-dev@...ts.openwall.com>
Subject: Request for Comments on .conf file .remove [section] processing
I was going to start on this one. I would like to present some ideas, and
ask others if they have ideas, of how this should work, or how this work
should be accomplished. Please post comments or suggestions at ANY part of
this email, even if not a question.
First, I think that only ".remove [section]" is valid. I do not find
.remove <file> to be valid in any way. I do not see how .remove <file>
could be implemented, nor do I see any usefulness. If others see benefit,
please speak up.
There are 2 type of sections. One is a "list", and one is "params". The
list type starts with [List. .] the param type does not.
For a param type section, I do not think removal is really useful, but I
could be wrong. I think to handle this one, I would simply spin through the
section being removed, and remove each name,value pair (ignoring the value)
found in that section, from the current section. This is an N^2 algorithm,
but usually, these sections are very small, only a few, to a few dozen
params.
Of the list type, there appears to be Rules, and externs (at this time). I
believe that handling The rules type will be pretty easy. The externs, may
be a little harder, but I want to ask some questions there.
For the rules, I think this:
1. Load the section to remove.
2. Append some 'magic' value to that section. Such as the rule:
CTWAR*END_OF_LIST_MARKER*CTXCTB
3. Point the end of that section to our building section.
4. Call the rules duplication removal function
5. Walk the list until we find the rule we appended in step 2.
6. Point the head of our building list to that that rule line points
to.
That should remove all rule lines found in the .remove list, which were
previously loaded into our list. The 'fake' rule marker in #2 should be
something that NO rule maker would ever use. It is simply supposed to be
something that is NOT part of the .remove section. Something ugly like
above should be plenty safe to have hard coded, but if we 'needed' to, we
could build this garbage rule on the fly, checking to make sure it does not
exist in the .remove list.
Does anyone have any comments, issues, suggestions, etc about the above
algorithm? It should run pretty quickly, since the main 'work' is in the
dupe rules reduction code, which is a O(n * ln n) algorithm.
Now, for the [List.External: type] sections. I can see the .remove [] being
useful, in building library of functions.
Filter types, probably have little to gain, since they only (usually?) have
a filter function. Thus, I am not sure what gain there would be. For
'normal' externs, where we generate code, I do see .remove being valuable.
However, is it useful, to be able to remove a section, and likely this would
have to be 'exactly' like the section in our current section? Or would it
be more useful to have special .remove commands, so we could do something
like: .remove [function name] .remove [variable name] to have one of these
2 types removed?
Let an example show:
[List.External:test]
int curlen, buffer[12], max;
void init()
{
max=12;
curlen=1;
buffer[0] = 'A'-1;
}
void generate()
{
/* do something here */
}
void restore()
{
/* do something here */
}
[List.External:test2]
.include [List.External.test]
.remove [variable buffer]
.remove [function init]
int buffer[16] /* NOTE, I see a proble here, because the generate() and
restore() function will now be above this buffer variable! */
void init()
{
int i;
max=16;
curlen=12;
for (i = 0; i < 12; ++i) {
buffer[i] = 'Z';
}
}
I know this post has sort of wandered around a bit. I wanted to start on
the .remove[] code, but I am running into technical problems, along with
usability issues.
I do think that adding a .remove [section] for a List.Rules: section should
be easy to do, and pretty damn useful. I also know that originally, I
simply implemented include of a file, and include of a 'rules' section,
thinking that was the only need, and Alex directed me to make it 'generic'.
Since that time, the generic model has proven to be much more
useful/powerful than how I originally implemented, and there are numerous
places where includes were useful beyond just a full file and rules. That
is why I am sort of tossing this question out there, hoping that others will
have ideas that make this more useful/powerful in the end.
Jim.
Content of type "text/html" skipped
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.
