🚀 go-pugleaf

Ka9q, here's a line from smtpserv.c:

        int no_check_dot = 0;   /* don't check for "." */

Does that make you go "GRRRR!" straight away?  Are such
programmers unaware, or sloppy thinkers, or do they have
brains the size of planets (complexity never a problem)?
Why do people use negatives in identifiers?  Is it a
cultural thing, perhaps?  Is it more common in Britain
than in positive thinking America?

But how is this variable used?

while (1)
    {
    int no_check_dot = 0;           /* don't check for "."              */
    ...
    if (no_check_dot == 0 && *p == '.')
        {
        ...
        }   /* if (no_check_dot == 0 && *p == '.') */

    if (has_newline != 0)
        no_check_dot = 0;           /* check "." next time              */
    else
        no_check_dot = 1;           /* don't check "." next time        */
    ...
    }

I've omitted detail, but those are ALL the lines that use
this variable.

If they served any purpose I'd also be carping about
using that if..else instead of a simple

        no_check_dot = !has_newline;

And now for something completely different...

Believe it or not, I wasn't browsing smtpserv.c to score
coding style.  Currently I have a problem with a 900K
mail that is waiting for me on 'punt'.  (Don't you just
love it when you mail a request to a server that gives
you no indication of how much it's going to hit you with?
But that's another story).  Ka9q receives this mail ok,
but then seems to "get stuck" at the end.  It won't even
respond to commands like 'so' or 'ex'.  Luckily I have an
external modem, and dropping power on it instantly frees
up ka9q.  However, it seems that the final part of the
SMTP handshake hasn't been done, because next time I log
on the mail is still waiting on Demon for me.

Anyone else had this problem, any clues where exactly in
the source the problem might be?  I'm aware that it may be
due to the delay while copying the temp file being too long
for the client, but I don't see why that should lock up
other processes.

As a kluge around it, I'm thinking of counting the incoming
lines, and if over a threshold changing the action.  Instead
of doing the copy I want to rename the temp file, so as to
speed up the response to the client.  Any thoughts on that?

More generally, I wonder whether this might be an interesting
route to go for all mail.  In essence, instead of copying
the mail to its destination file when the '.' is received,
leaving the file to be processed offline.  Result would be
shorter time online, as well as greater resilience to the
timeout problem.  However, I'm not familiar with how ka9q
handles its temp files -- does that sound workable?

--
John Washington