[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Nmh-workers] nmh internals: argument processing

From: Ken Hornstein
Subject: [Nmh-workers] nmh internals: argument processing
Date: Mon, 07 Jan 2013 18:52:43 -0500

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

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:

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?


reply via email to

[Prev in Thread] Current Thread [Next in Thread]