[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
[tor-bugs] #8351 [Tor]: Refactor our controller-command/torrc-option processing logic into a data-driven function
#8351: Refactor our controller-command/torrc-option processing logic into a data-
driven function
------------------------------------+---------------------------------------
Reporter: nickm | Owner:
Type: enhancement | Status: new
Priority: normal | Milestone: Tor: 0.2.5.x-final
Component: Tor | Version:
Keywords: tor-client refactoring | Parent:
Points: | Actualpoints:
------------------------------------+---------------------------------------
Throughout our controller protocol and our configuration code, we process
things with more or less the following metaformat:
{{{
Line = PositionalOptions | KWDOptions | BothOptions
BothOptions = PositionalOptions SP KWDOptions
PositionalOptions = PosOption | PosOption SP PositionalOptions
KWDOptions = KWDOption | KWDOption SP KWDOptions
PosOption = QuotedOption | NonSpace
QuotedOption = QString
NonSpace = PChar*
KWDOption = KWDName "=" PosOption
PChar = a printing, nonspace character.
QString = DOUBLE_QUOTE QContent* DOUBLE_QUOTE
SP = One or more whitespace characters
}}}
We should have one generic function that parses a config line or command
into a list of positional and keyword arguments, and another that takes
such a list, typechecks it, and converts it into a structure (in the same
way that config_assign does). The latter function could even _be_
config_assign.
In theory, this should make our parsing more convenient, and remove a
bunch of duplicate code.
(Did I already open a ticket for this? I'm not seeing it if so.)
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/8351>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs