syslogd: Only use peerlist during flag parsing

[jfree]

Summary

Add logging sockets directly to the socklist, unless parsing flags. The
peerlist is still needed to temporarily hold socket information until
the configuration flags have been parsed.

It is tempting to remove the entire peerlist, but addsock() can not
determine if syslogd is in secure mode unless the flags have been
parsed.

Also, call pidfile_open() right after flag parsing so we can terminate
if another syslogd instance is already running.

[markj]

usr.sbin/syslogd/syslogd.c

591

Why does this have to be a macro?

[jfree]

Address Mark's comments

[jfree]

Bring back peerlist -- see updated patch summary

[markj]

This diff is a bit on the large side. A few bits could have been split off into separate patches, e.g., changing the return type of allowaddr(). It can be tedious to split up patches, but it really does help when one has to read 20+ patches in a row. :) Just a general comment, I'm not asking you to split things further.

usr.sbin/syslogd/syslogd.c

492–493

style(9) discourages mixing declarations and initializations. The old code was ok.

3789

Can we make ai a pointer to const?

[jfree]

usr.sbin/syslogd/syslogd.c

492–493

style(9) discourages mixing declarations and initializations. The old code was ok.

Maybe I am misinterpreting, but I don't think it discourages this...

"Variables may be initialized where declared especially when they are constant for the rest of the scope. Declarations may be placed before executable lines at the start of any block. Calls to complicated functions should be avoided when initializing variables."

The pe pointer value is constant for the remainder of the scope and I wouldn't call calloc() a particularly ambiguous or complex function.

[markj]

usr.sbin/syslogd/syslogd.c

492–493

I read that as saying that calls to functions like device_get_softc(), which never fail, are ok, but function calls which require error handling or have side effects are not.

[jfree]

usr.sbin/syslogd/syslogd.c

492–493

I read that as saying that calls to functions like device_get_softc(), which never fail, are ok, but function calls which require error handling or have side effects are not.

Fair, that is a good way to approach it.