Since we've been talking about the format language, there is something
I've wanted to clean up for a while: the format compiler/interpreter's
memory management.
The format routines don't have a very clean API, and there is a lot of
exposure of the internals of the format implementation to other programs.
And some of the memory management is a bit weird. Exhibit A: see
uip/replsbr.c:replout(), specifically "compbuffers" and "nxtbuf". Okay,
what happening there is that in the name of efficiency every time a
component we are interested in is "seen" by us, we switch out the current
buffer we're using with a new one and save the old buffer (which contains
the contents of that component) in the hash table.
I'm sure back in the days of a VAX 11/750 that made sense, but now? I'm
thinking we'd never notice the string copy.
In addition to that, calling the format compiler more than once per program
is problematic. Exhibit B: uip/mhlsbr.c:compileargs(). The problem here
is twofold: the format instructions contain pointers to the hash table
entries and thus memory is leaked every time fmt_compile is called (okay,
it's never freed NOW, but still) and if you want multiple format strings
to refer to the same message, you have to go through all of these
contortions to make it work.
To explain that, here's how things work now:
- You call fmt_compile(): hash table of "interesting" components is reset
and built anew. Any component you care about it your format string is
stored in a hash table. Each format instruction referencing a component
points to the component entry in the hash table.
- You call m_getfld() and you peek in the hash table every time you get
a new component. If that component is in there you store the
component text in the hash table entry.
- When you call fmt_scan(), the component text for each component is retrieved
from the hash table as needed.
The problem is if you call fmt_compile() multiple times and then
want to interpret each set of instructions on the same message, you'll
only have the correct component hash table from your last call to
fmt_compile(). My code to support reply filters was the first time
anything has wanted to do that, hence the nasty mess I have in there
now.
So, I'm proposing that I clean up the API and simplify the memory management
(although it looks like I'm going to have to refcount the component hash
table entries to make it work right). Objections? Okay, fine ... a better
language would be nice. So little time ...
--Ken
_______________________________________________
Nmh-workers mailing list
Nmh-workers(_at_)nongnu(_dot_)org
https://lists.nongnu.org/mailman/listinfo/nmh-workers