Re: [Nmh-workers] m_getfld

[Paul Fox]

ken wrote:
 > >> i would have rewritten m_getfld.c a year ago if i hadn't thought that
 > >> its API layering was one of its big problems and that a correctness
 > >> preserving transformation of code that implements a bad idea is not the
 > >> way to improve the overall system. maybe i was wrong.
 > >
 > >I don't think so.  There are 78 or so call sites and it's
 > >used for different purposes.  I think that getting to a
 > >decent API is much more important and a better investment.
 > 
 > Well ... let me offer some counter-points:
 > 
 > - Out of those 78 call sites, we have:
 > 
 >   - 2 reading the config file
 >   - 3 reading sequences
 >   - The rest read RFC-822 messages
 > 
 >   The first two of those seem a bit odd, until you realize that both the
 >   config file and sequences files are in the format of the headers of an
 >   RFC-822 message.  So saying that they're for different purposes is a

hah!  i noticed that something was amiss with config file parsing when
i hit a syntax error, and was eventually got rid of it by adding a ':'
to a commented out line.

it turns out i've been commenting out entries in .mh_profile for years
by putting a '#' on the front.  ("#send: -msgid -mime")  and i guess
that only works because the parser still finds a ':' somewhere in the
line, and the '#' changes the name of the profile-component in a way
that's unlikely to conflict.

now that i know it's "just" an rfc-822 header, it all makes sense.  ;-)
(it also totally dissuades me from trying to add real comment support.  ;-)

paul

 >   bit misleading ... all of the uses are for reading something which has
 >   the format of an RFC-822 message.  I think changing all of those would
 >   be fine, since they all use m_getfld() the same way.  A few optmizations
 >   actually come to mind that could clean it up.
 > 
 > - I'm fine with a new API; that would be wonderful.  But I have a few rather
 >   boring practical question to ask: who, exactly, is doing this work, and
 >   what timeframe are we talking about?
 > 
 >   These are critical questions.  m_getfld() is our biggest portability
 >   nightmare due to it's peeking into stdio internals; getting rid of that
 >   nastiness is very important.  If we're not fixing that because we're going
 >   to junk the whole thing due to a wholesale API replacement, great.  But
 >   when is that API replacement going to happen?  If it's months, great.
 >   If it's years ... well, I'd vote for fixing m_getfld() now.
 > 
 >   And who is doing the work, exactly?  Paul is kinda busy saving the
 >   goddamn Internet (http://www.circleid.com/posts/20120327_dns_changer/)
 >   and I get the sense Lyndon doesn't have tons of free time.  David, I
 >   know you do a lot; if you're signing up for this, then please say so.
 >   I'm not afraid of big projects, but right now I don't have the time for
 >   something this intricate.
 > 
 > >> let me ask: if i fix m_getfld.c by replacement, including major changes
 > >> at every call site, would that patch get any daylight? i'm not unwilling
 > >> to work on it, i'm just unwilling to let the work languish because it's
 > >> too "edgy" for a conservative code base.
 > >
 > >I'm confident that the test suite ("make check") can verify
 > >correctness.  It doesn't check performance, but I expect
 > >that enough of us have big folders we can run inc, pick,
 > >etc., on.  And a variety of perf tests would be welcome.
 > 
 > I'm with David here; I think the test suite does a reasonable job of
 > verifying correctness; we've added a bunch of corner-case tests over
 > the years.  And as for "edginess" ... well, I'd be glad to take any
 > changes Paul makes with regarding to m_getfld() and work to get them
 > in the tree.
 > 
 > --Ken
 > 
 > _______________________________________________
 > Nmh-workers mailing list
 > address@hidden
 > https://lists.nongnu.org/mailman/listinfo/nmh-workers

=---------------------
 paul fox, address@hidden (arlington, ma, where it's 36.1 degrees)