[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Nmh-workers] nmh internals: argument processing
From: |
Lyndon Nerenberg |
Subject: |
Re: [Nmh-workers] nmh internals: argument processing |
Date: |
Mon, 7 Jan 2013 16:50:18 -0800 |
On 2013-01-07, at 3:52 PM, Ken Hornstein wrote:
> 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?
FWIW, the Plan 9 idiom for this is something like:
enum {
AUDSW = 0,
NAUDSW,
CHGSW
NCHGSW,
...
}
typedef struct swit switches[] {
{ "audit audit-file", 0},
...
}
The advantage is having symbolic values in the source debugger rather than
opaque translations from cpp. I'm all in favour of this. It's a godsend when
you're tracing code.
- [Nmh-workers] nmh internals: argument processing, Ken Hornstein, 2013/01/07
- Re: [Nmh-workers] nmh internals: argument processing,
Lyndon Nerenberg <=
- Re: [Nmh-workers] nmh internals: argument processing, Ralph Corderoy, 2013/01/07
- Re: [Nmh-workers] nmh internals: argument processing, Ken Hornstein, 2013/01/07
- Re: [Nmh-workers] nmh internals: argument processing, Ralph Corderoy, 2013/01/08
- Re: [Nmh-workers] nmh internals: argument processing, Paul Fox, 2013/01/08
- Re: [Nmh-workers] nmh internals: argument processing, Ken Hornstein, 2013/01/08
- Re: [Nmh-workers] nmh internals: argument processing, Ralph Corderoy, 2013/01/08
- Re: [Nmh-workers] nmh internals: argument processing, Ken Hornstein, 2013/01/08
- Re: [Nmh-workers] nmh internals: argument processing, Ralph Corderoy, 2013/01/09