Re: [Nmh-workers] m_getfld

[Ken Hornstein]

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