[2023-09-02 14:41] Ken Hornstein <k...@pobox.com> > >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.
Actually not quite, I think step by step. First get a good function parsing the fields. Then look how this function can be used to parse the complete header. > 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). I would split up your second case in two: - One where all fields are read and processed, but some fields are processed in a special way (like post) - One where only some fields are needed (like pick) > 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. > [...] > I realize that this is a larger project and if someone just wants to > improve m_getfld() that is fine with me. A function to parse the complete header would be nice, but as you mention this is a larger project. The problem header parsing is required everywhere in nmh. Implementing such a function direct would required to either rewrite every m_getfld user at once or having two parser at the same time. So to separate this first improve the field parser and build a high level API based on this parser. This way there would only one parse and the single programs could be updated step by step. > 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. Because I have not that much experience with flex, I have handcrafted my m_getfld. But using flex (and yacc) sounds like a good idea. > But really I think there should be a higher level > API to deal with header fields rather than have nmh code call m_getfld(). Some time ago I have started a getfields() function for this. This function collect either all fields or the one specified by a filter. When you are interested in it, I can share it. Philipp > --Ken >