🚀 go-pugleaf

Just poking around the source (as one does...) I came across
a problem in the 'remlist()' func in smtpserv.c - that is,
the official one on ftp.demon.  Knowing how tight ka9q is
for mem, it strikes me it would be a good idea to fix it.

This version has:
    ...
    for (ptr = *head; ptr; ptr = ptr->next)
        if (ptr == unwanted)
            {
            *prev = ptr->next;
            free (ptr);
            break;
            }
        else
            prev = &ptr->next;
    ...

There ought to be a 'free (ptr->val);' just before the 'ptr'
is 'free'd - maybe not a big deal, but could be if one's
ALIAS file is largish or one subscribes to big mail lists.
The 'del_list()' in smtpcli.c is fine.

And talking of lists, some memory might be reclaimed by
rationalising them across ka9q:  I've only looked so far at
smtpserv and nntpcli with a view to producing a unified
kill/keep facility and there is duplication of effort even
in the live code :(  smtpserv.c has a 'struct list ..' and
nntpcli.c has a (similar) 'struct textline ..' - both with
their own sets of functions to manipulate them.  (OK, they're
not exactly the same, but alike enough to ignore the 'type'
member in the nntp stuff.)  I've no doubt there are similar
linked lists[1] defined elsewhere too...

And another thing: 'struct textline' is defined in nntpcli.c
as:

struct textline
    {
    struct textline *nextline;      /* pointer to next text line */
    char text[NNTPMAXLEN];   /* array holding text (shrunk to fit) */
    };

which is a profligate waste of mem - most kill entries will
be less than 512 bytes long (one hopes..) so it should be more
efficient to define 'text' as char * and replace the 'strcpy'
with a 'strdup' even with the extra 'free' call afterwards.

And another thing!  The 'createkilllists()' func takes no
special action for empty or comment lines - they get their
own 500+ byte buffers just like proper entries.  At least the
smtp code checks for and skips these lines with its lists.
All such lines now removed from my killfile :-)

[1] I didn't like either of these, so my PEEL util has yet
another variety[2].  Guilty as charged...

[2] But I reckon the manipulating funcs are more efficient -
well, I would wouldn't I?
-- 
Pete
(Who spends much of his working life cramming Z80 code into 48Kb)