Hi
Because of the work on getfields() and readmbox() I have notized some
problems in m_getfield and the API. I have already mention the EOF2
status and the LENERR2. But this thread should collect all changes I
currently plan to m_getfld2().
I mentiont in the first discossion of m_getfld2, that I don't want to
change the API. This is kindof still true. I would like to keep the old
API, but there are problems I would like to fix. These problems could
also seen as bugs in the API. Not critical bugs, but I would like to
fix them.
So where are the problems. First the enum status contains miss the end
of header status. Also the LENERR2 status isn't realy match for this
enumeration. So I would like to add the EOH2 status like in the patches
for getfields and remove the LENERR2.
structs fields contains a boolean (unsigned char) crlf. Actually there
should be more then this. By a quick look I identified three boolean we
should have: crlf, lenerr and obsolet header (rfc 5322 4.5. Obsolete
Header Fields). Maybe there are more I haven't found yet. So I would
suggest to replace the crlf member a general flags member. Also an enum
fields_flags with contains { crlf, lenerr, obs } at the moment. This
way we can easy add more flags.
The biggest problem is the name member. Currently it's a 999 byte big
char array[0]. Conssidering that a line in a mail is most of the time
not longer then 78 bytes and most fields fit in one line, this is a huge
waste of memory. Also in the body part this array isn't even used. In
the old style handle the header field by field, this may be not that
bad, but with the new getfields() and readmbox() function this is a big
waste. So I would change this to a pointer and add an member for the
allocation length.
A small inprovent without changing the API would be to reuse the
allocation of value in the body (and with this changes also the fields).
Currently m_getfld2 frees f->value and reassige a tmp char* which is
allocated by getline(). I don't conssider this as an optimization, more
as removing an degradation.
If we apply these changes I considder the m_getfld2() API finished.
But I'm only a human and also considerd that the the API was finished
last time this was discossed. So now it's the best time to comment on
this API. Did I missed some cases? Have I overseen a big loophole in
the API? Are there other problems with m_getfld2(), the structs/enums?
Philipp
[0] This char array is a relic of the old m_getfld(). The m_getfld()
had a parameter name with the impliziet length NAMESZ. So all tools
just had a char name[NAMESZ] for m_getfld(). I have just took this
parameter and put it in the fields struct without think about the
consequences.
