[Nmh-workers] nmh internals: argument processing

[Ken Hornstein]

This is mostly about nmh internals, but it's been bugging me for a while
now.

nmh uses a function called smatch() to parse options.  You give it a
"struct swit" array, which contains the following members:

        char *sw;       /* Name of switch */
        int minchars;   /* Minimum number of characters to match switch name */

smatch returns an index into the "struct swit" array.  If you've looked at
nmh code, you've seen plenty of stuff like this (from inc.c):

static struct swit switches[] = {
#define AUDSW                      0
    { "audit audit-file", 0 },
#define NAUDSW                     1
    { "noaudit", 0 },
#define CHGSW                      2
    { "changecur", 0 },
#define NCHGSW                     3
    { "nochangecur", 0 },
[...]

So the "fun" part here is that humans have to deal with manually keeping
these defines matched up to the index into the swit array, and if you add or
delete switches you have to adjust all of the #define's after your
change.  This annoys me to no end, and I've been thinking lately: Why I am
doing this, exactly?  Why isn't the compiler doing it for me?

It occurs to me that it would be simple to add an extra element to the
struct swit that included the value to return, so these things could be
automatically indexed via enum (or whatever).  In other words, the above
code would convert to:

enum { AUDSW, NAUDSW, CHGSW, NCHGSW, };
static struct swit switches[] = {
    { "audit audit-file", 0, AUDSW },
    { "noaudit", 0, NAUDSW},
    { "changecur", 0, CHGSW },
    { "nochangecur", 0, NCHGSW },

And the rest of the code would work normally.  Thoughts?

--Ken