Closed
Bug 262336
Opened 20 years ago
Closed 20 years ago
Command manager's argument parsing can't properly handle leading optional parameters.
Categories
(Other Applications :: ChatZilla, defect)
Other Applications
ChatZilla
Tracking
(Not tracked)
RESOLVED
WONTFIX
People
(Reporter: justinarthur, Assigned: rginda)
References
()
Details
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8a1) Gecko/20040618
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8a1) Gecko/20040618
The parseArgumentsRaw method of CommandManager objects currently works fine for
commands that have trailing optional arguments. It will also work fine for
commands that have leading or middle optional arguments AS LONG AS each argument
is satisfied up to the last required argument. However, if you were to waive an
optional leading argument, you can end up not satisfying the requirements under
the current checking system, which looks something like this:
if (e.currentArgIndex < argc && currentArg != ":") { /* ended on a required
argument without enough supplied arguments to fill it */}
There are not too many commands identified with leading optionals in rfc2812,
but I think it is important for ChatZilla to have this flexibility. One command
where this is a problem is the WHOIS command which the RFC defines the following
parameter structure for:
[ <target> ] <mask> *( "," <mask> )
It isn't possible to correctly implement this command as defined under the
current system. If I were to change cmd.whois.params to equal "[<querytarget>]
<nickname>" to closer match the RFC's specification, I would run into a problem
if one tried to use the whois command and only supply the nickname argument. It
would fill in the querytarget argument with the supplied nickname, and then the
above mentioned code segment would execute and test true because parsing ended
on a required parameter. One solution is to test whether the amount of supplied
arguments matches the amount of required options, and if that is the case, do
not fill up any optionals.
Reproducible: Always
Steps to Reproduce:
Actual Results:
[ERROR] Missing required parameter nickname.
Updated•20 years ago
|
Status: UNCONFIRMED → NEW
Ever confirmed: true
Assignee | ||
Comment 1•20 years ago
|
||
Ignoring the fact that leading optionals are a bad idea in the first place, the
only code capable of determining whether or not a leading optional parameter was
included or not is the code that's going to run the command. How do you propose
to generalize something like this into a parser?
Reporter | ||
Comment 2•20 years ago
|
||
Objections to this "bogus" approach have been sustained. I would still like to
see to its resolution, and welcome anyone to submit comments or proposed patches
to this bug if they have any input, but will mark the bug as wontfix for the
time being. An alternative solution for bug 150140 will have to be determined.
Updated•20 years ago
|
Product: Core → Other Applications
You need to log in
before you can comment on or make changes to this bug.
Description
•