[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Nmh-workers] m_getfld
From: |
Ken Hornstein |
Subject: |
Re: [Nmh-workers] m_getfld |
Date: |
Sun, 09 Dec 2012 16:53:16 -0500 |
>> 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
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