Re: some thought on m_getfld

[Ken Hornstein]

>I'm not sure if it's a good idea to start this topic, but it bugs me a
>bit. Also as a disclaimer my view on this is highly influenced by my own
>m_getfld variant[0].
>
>Because of the missunderstanding of when LENERR is used I have looked
>at m_getfld.c and I see some problems with the interface and the
>implemetation.
>[...]

First, my apologies for not contributing more on the discussion regarding
header folding; my life has been busy as of late.  But I have some thoughts
on this.

I think you are thinking at the wrong scale.  The problem with m_getfld()
is not the interface, it is that it should not exist at all.

As you note, there's a ton of duplicated code when dealing with m_getfld().
This has led me to believe that the number of programs that actually need
a m_getfld()-style interface is close to zero.  I think programs tend to
fall into two styles of header access:

- One where they process each header field at a time (like the config file
  parser).
- One where they need to slurp in all header fields and then just extract
  the ones they care about (I think this is the most common).

So this suggests to me that really in most cases the whole header should
just be read and then you get some accessor functions to get out the
headers you care about.

In terms of implementation, as you note header fields have a well-defined
structure so honestly my preference would be to write a flex lexer to
process header fields.  But really I think there should be a higher level
API to deal with header fields rather than have nmh code call m_getfld().

I realize that this is a larger project and if someone just wants to
improve m_getfld() that is fine with me.

--Ken