[Top][All Lists]

[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:




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.)


 > 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)

reply via email to

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