Re: Argument parser

[Yoshinori K. Okuji]

On Monday 15 December 2003 23:51, Marco Gerards wrote:
> Ah, ok.  It is not hard to implement IMO.  The logic is in the parser
> (which is small as well).  Perhaps it looked hard to you to implement
> a parser using what I proposed.  I think this is actually is easier
> to do.  The produced binary won't be too big I think because most
> lines are just descriptions of the arguments and parts of the switch
> statement.

I'm afraid that it is impossible for me to tell you what I mean without 
actually starting using your parser.

> It does not have to be complex (see my code, it is not complex IMHO).
> All the parsing is done by the global parser, the command doesn't
> need to do anything to special to support GNU features.  I like
> putting the burden at one single place so it is not required to do
> much parsing in the command itself.

Then, please write simple code to aggregate arguments into an array. 
This is too much for most commands.

> It is not hard to support the GNU way with this little code.  Do you
> think the parser is still to big? (It's 10% of the code of the
> smallest popt implementation...)

I don't care about the size so much, but I want to avoid unneeded 
complexity.

> What do you exactly mean with the POSIX way?  Only short options?

See the section COMPATIBILITY in the manpage of getopt(3).

> What would you like to see?  Should I change my parser by calling the
> command with the "char *args[]" like I explained in my previous mail
> or do you want to see more changes or something completely different?

My argument is that it is too much for most commands to construct a 
linked list only, say, to support a variable number of arguments.

Most of GRUB commands are about 20 lines. So, if you enforce writing 
code to aggregate arguments, this part can be more than a half of the 
whole code quite easily. And, dynamic memory allocation is quite 
error-prone, as you know.

Okuji