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)
Nmh-workers mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/nmh-workers