Re: RFA: gdb/783 doc change

[Andrew Cagney <ac131313@redhat.com>]

> J. Johnston writes:
>  > The following changes the mi documentation to clarify the usage of the
>  > "--" delimeter.  This delimeter is meant to provide a way to separate
>  > options from parameters so as to handle cases whereby the parameters may
>  > start with "-" and be mistaken for options.  


>  > The problem reported tries to use it generally before any parameter list.
>  > This doesn't work because only the mi_getopt option processor knows to ignore it and
>  > commands that don't have options (preceded by dash) don't call mi_getopt.
>  > It is then treated as a parameter which is incorrect.

>  > I have removed the delimeter from the description of the -data-disassemble
>  > command as it is not manditory and the delimeter should be treated as optional to all 
>  > applicable commands that support both options and parameters.  I have removed
>  > it from one of the -data-disassemble examples to clarify that it may or may not
>  > be specified.

The documentation is correct, there is no reason for changing it.

All MI commands should use mi_getopt() as by doing this the MI can 
present a very consistent command line interface to its users.  Contrast 
this to the UNIX and GDB CLI interfaces, each individual command has its 
own eseoteric edge conditions (and the user needs to work around each 
individually).  The ``--'' problem is just one of the cases that 
mi_getopt() handles, another is c-strings (see below).

In case you're wondering, the commands that don't use mi_getopt() 
pre-date that function's implementation (and one has gone back and 
updated them).

For the most part converting commands to use mi_getopt() should be 
straight forward.  There are exceptions though, some of the older 
commands pulled a very GDB CLI like hack by accepting:
	-command -opt x this is the "final" parameter
when they should have accepted:
	-command -opt x -- "this is the \"final\" parameter"
such a change will get messy and might mean replacing the command.

>  > Ok to commit?

No.

Andrew