Paul V. wrote:
mmap needs a file descriptor.
fileno() would take care of that. But . . .
we need a way way way better way to talk to
the message interface. in fact we need a message interface. and for all
i know some of m_getfld's callers are passing in a socket or a pipe
sometimes.
Ah, yes, that could be a problem. On the other hand, I took a
quick look at rcvdist and slocal. They read from stdin but copy
to a tmp file that's used with m_getfld.
We can reduce the m_getfld call site count by 1: the one in
inc is in a dead code block. And it wouldn't have worked
because it wouldn't terminate. I still think it deserves to
be added to Ken's list of amazing uses of m_getfld: to
simply copy a FILE.
i remember looking at the MH source code after i'd been using it about a
year. so, maybe 1986? anyway i saw that there was no middleware layer,
no way to write my own C utility that could benefit from MH's libraries
and do interesting high level things with mail messages.
And Jon wrote:
# I would like any m_getfld replacement to have the ability to extract
# information about MIME message parts which means finding headers in
# the middle of bodies. As per postings some years ago, I would like to
# add code for reading attachments that needs this feature.
I think that m_getfld should retain its current interface,
unless it needs to be fixed or can be tidied up to benefit
those 72 callers. It should continue to spit out header
fields and a body. Message parts should be provided by some
layer, with a more natural API, that's above it.
David
_______________________________________________
Nmh-workers mailing list
Nmh-workers(_at_)nongnu(_dot_)org
https://lists.nongnu.org/mailman/listinfo/nmh-workers