[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
additional changes (was Re: POP3d locking)
From: |
Alain Magloire |
Subject: |
additional changes (was Re: POP3d locking) |
Date: |
Mon, 30 Apr 2001 00:56:01 -0400 (EDT) |
Bonjour
> Some additional changes that were made:
>
> 1. locker_lock while trying to read pid value from the pidfile
> passed wrong buffer length to read() call, namely:
>
> read(fd, buf, sizeof (pid_t))
>
> whereas buf was declared as buf[16]. Consequently, most of the
> time the process was considered dead, unless his pid consisted
> of three decimal digits.
Absolutely!
patch in.
> 2. Return values of all signal handlers are changed to RETSIGTYPE
> and configure.in is modified accordingly. This is more portable.
Ok, patch in.
> 3. Current implementation of pop3d_signal would cause main process
> to attempt to perform fprintf on NULL file pointer (ofile). Sure,
> the main process should not crash, but one never knows... So I
> have modified pop3d_signal to handle this appropriately.
Do not see why:
===== pop3d.c ======
int
pop3d_mainloop (int infile, int outfile)
{
int status = OK;
ifile = infile;
ofile = fdopen (outfile, "w");
if (ofile == NULL)
pop3d_abquit (ERR_NO_OFILE);
...
}
This pretty much guaranty that ofile will not be NULL and if it is
the server will immediately exit.
But this remind me, that I do not see a difference between
ERR_NO_FILE or ERR_DEAD_SOCKET. If the socket is dead (read() == -1)
no need to try to fprintf (ofile, ..) to it. Unless Jakob had another
reason?
> Additionally, revising uidl.c I noticed that uild buffer is declared
> as char uidl[128]. RFC sais it is 70 octets + newline character.
> Should we be more RFC compliant?
message_get_uidl() should not send more then 70 chars when
running the md5 sum but if you want to send a patch for this
I will apply it.
> Well, for the time being, that is all. The patch follows.
Ok, When CVS wil be up again I'll checking the changes.
--
alain