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
Nmh-workers(_at_)nongnu(_dot_)org
https://lists.nongnu.org/mailman/listinfo/nmh-workers
=---------------------
paul fox, pgf(_at_)foxharp(_dot_)boston(_dot_)ma(_dot_)us (arlington, ma,
where it's 36.1
degrees)
_______________________________________________
Nmh-workers mailing list
Nmh-workers(_at_)nongnu(_dot_)org
https://lists.nongnu.org/mailman/listinfo/nmh-workers