[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Nmh-workers] nmh internals: argument processing
From: |
Paul Fox |
Subject: |
Re: [Nmh-workers] nmh internals: argument processing |
Date: |
Wed, 09 Jan 2013 10:25:52 -0500 |
does this solution lead to symbols that can't be found with
simple search tools? a quick skim made me think it doesn't, but
wanted to check. i.e., will i find a reference to, say, MARK_FOO
in the code that i can't grep for, because it was constructed with
name ## _FOO
or something like that?
if not, i'm all for it. otherwise i think the obfuscation isn't worth it.
(the linux kernel is full of variable names constructed like that,
making it very difficult to find important declarations.)
paul
ken wrote:
> >Hope this clairifies, ask if anything's unclear.
>
> Yes, it does; thank you! Actually, I think I do like this; I started
> doing this conversion for a few files yesterday, and it did strike me
> as a bit inelegant to have to do the enum separately from the struct swit
> array. Even though it's a bit of hack, I like it.
>
> But ... it still somehow sticks in my craw the idea of returning an
> array index. It just seems wrong to me, somehow. So I'm going to change
> your second #define for X to be:
>
> #define X(sw, minchars, id) { sw, minchars, id },
>
> >I added the `array' parameter to DEFINE_SWITCH_ARRAY(); before I just
> >always called the array `switches'. The blank line after
> >MARK_SWITCHES's definition is significant.
>
> How come? It looks like you could either have the blank line after the
> definition, or simply omit the last \. Of course, I could be missing
> something :-)
>
> >The LEN_MARK enumerate is to avoid the trailing comma in an enum;
> >illegal in C89. The name is embedded to make it unique and it's useful
> >on other occasions, e.g. not having to NULL-terminate the array.
>
> Thanks for explaining; I was wondering about that!
>
> --Ken
>
> _______________________________________________
> Nmh-workers mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/nmh-workers
=---------------------
paul fox, address@hidden (arlington, ma, where it's 32.7 degrees)
- Re: [Nmh-workers] nmh internals: argument processing, (continued)
- 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
- Re: [Nmh-workers] nmh internals: argument processing, Ken Hornstein, 2013/01/09
- Re: [Nmh-workers] nmh internals: argument processing,
Paul Fox <=
- Re: [Nmh-workers] nmh internals: argument processing, Ralph Corderoy, 2013/01/09
- Re: [Nmh-workers] nmh internals: argument processing, Paul Fox, 2013/01/09
- Re: [Nmh-workers] nmh internals: argument processing, Ralph Corderoy, 2013/01/09
- Re: [Nmh-workers] nmh internals: argument processing, Ken Hornstein, 2013/01/09
- Re: [Nmh-workers] nmh internals: argument processing, Ralph Corderoy, 2013/01/09
- Re: [Nmh-workers] nmh internals: argument processing, Ken Hornstein, 2013/01/09
Re: [Nmh-workers] nmh internals: argument processing, David Levine, 2013/01/08