nmh-workers
[Top] [All Lists]

Re: [Nmh-workers] m_getfld

2012-12-09 15:53:28
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

_______________________________________________
Nmh-workers mailing list
Nmh-workers(_at_)nongnu(_dot_)org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

<Prev in Thread] Current Thread [Next in Thread>