[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 11:30:32 -0500 |
ralph wrote:
> Hi Paul,
>
> > 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?
>
> There's MARK_SWITCHES that's defined and never used directly. But then
> it's indirectly used immediately afterwards by the next two paragraphs.
> The code that uses the array, e.g. `switches', uses the same identifier
> as is passed to DEFINE_SWITCH_ARRAY() so there's a match for `grep -rw'
> or similar there. The enumerates are being specified in full; although
> they have a common `SW' suffix in the mark.c example I didn't think the
> saving/obsfucation a good trade-off.
i see. so the bulk of the symbols are findable.
i'm not sure moving the "_SWITCHES" suffix into DEFINE_SWITCH_ENUM and
DEFINE_SWITCH_ARRAY is worth it, and i don't see that it's necessary.
if the invocations were:
DEFINE_SWITCH_ENUM(MARK_SWITCHES);
and
DEFINE_SWITCH_ARRAY(MARK_SWITCHES, switches);
then there would be one less hidden symbol in the world. it would change
the auto-generated length token from LEN_MARK to LEN_MARK_SWITCHES, but
i'm not sure that matters.
(but perhaps i'm missing something else.)
paul
>
> Cheers, Ralph.
>
> _______________________________________________
> Nmh-workers mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/nmh-workers
=---------------------
paul fox, address@hidden (arlington, ma, where it's 34.2 degrees)
- Re: [Nmh-workers] nmh internals: argument processing, (continued)
- 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, 2013/01/09
- Re: [Nmh-workers] nmh internals: argument processing, Ralph Corderoy, 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, 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