nmh-workers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

some thought on m_getfld


From: Philipp
Subject: some thought on m_getfld
Date: Sat, 02 Sep 2023 18:37:58 +0200

Hi

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.

Let's start with the interface:

m_getfld takes a char *buf and an int *bufsz for the field body and
length. The bufsz is used as input and output parameter. If a field
exceeds the legth of the of the buffer FLDPLUS is returned and the
caller is responsible to call m_getfld again and concat the field body.
Most callers use fmt_appendcomp in a loop to do this.

This leads to a huge amount of duplicated code. I would say m_getfld
should dynamic allocate the buffer. This way m_getfld could returen
exact one field per call. For the body m_getfld should return one line
per call.

Next let look at LENERR and FMTERR. FMTERR is to indecate a format error
and LENERR indicates that the field name is to long. I don't see why to
distinguish these errors and most of the code handle them the same way[1].

Speaking of length, when the caller would like to know if a field
contains a line with more then 998 bytes he has to check it on it's own.
But for m_getfld this would be simple to check. I know this would be
ignored in most cases. But for mhbuild and post this could be usefull.

m_getfld also supports mbox and MMDF. There are only a few places where
this is necesary. With a field/line based API it would be quite easy to
implement this on top of m_getlfd.

Next lets look at the implementation:

For fields m_getlfd reads byte by byte from it's internal state and
checks how to handle it depending on the current situation. A header
is quite good structured so in most cases something like strchr could
be used.

There is this complex state struct which mimics some parts of buffered IO.
Is this realy necesary? I have avoided implementing buffered IO myself
by using getline(3). There might be other ways to implemet this without
a so complex state.

I don't want to tell you how you have to implement m_getfld. I just hope
my view on this helps you to improve m_getfld. 

Philipp

[0] 
http://git.marmaro.de/?p=mmh;a=blob;f=sbr/m_getfld2.c;h=b9a618d166e245a37854003610f5a9cb1576ef0c;hb=HEAD

[1] at the cases I have looked at there is not even an indication in the
    error message which sate caused the error



reply via email to

[Prev in Thread] Current Thread [Next in Thread]