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)

defect
Not set
normal

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.
Blocks: 150140
Status: UNCONFIRMED → NEW
Ever confirmed: true
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?
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.
No longer blocks: 150140
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → WONTFIX
Product: Core → Other Applications
You need to log in before you can comment on or make changes to this bug.