additional changes (was Re: POP3d locking)

[Alain Magloire]

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