The assert(client != NULL) got triggered during our tests, so there is
an error path that resulted in the connection being still established
(sock >= 0) but the client structure already freed.
So Conn_Write() should handle it!
This reduces the possibility of flooding channels with commands like
"PRIVMSG/NOTICE #a,#n,#c,... :message" a little bit.
Problem noticed by Cahata -- thanks!
Until now, the penalty time has only been set when longer as the
already set one, so it didn't accumulate.
And add documentation for and clean up code in Conn_SetPenalty() and
Conn_ResetPenalty() functions.
This partly closes bug #118. ngIRCd still starts up even when
Server{UID|GID} is invalid: then the daemon falls back to "nobody"
when running with root(0) privileges (as before).
commit 15fec92ed7
(Update list item, if it already exists) can make ngircd
crash because 'Reason' can be NULL, as reported by
Cahata on the ngircd mailing list.
Doesn't affect any released ngircd versions.
Also, make sure that we do not pass NULL as arguments
to a '%s' printf-like function.
When JOIN is received with more than one channel name, don't stop
processing on the first error (e.g. bad name, wrong channel key, ...)
but report an error and continue with the other given channel names.
Reported by Cahata -- thanks!
When "PAMIsOptional" is set, clients not sending a password are still
allowed to connect: they won't become "identified" and keep the "~"
character prepended to their supplied user name.
This fixes two bugs:
- "WHO <nick>" returned nothing at all if the user was "+i"
(reported by Cahata, thanks).
- "WHO <nick|nickmask>" returned channel names instead of "*"
when the user was member of a (visible) channel.
Clean up code and add documentation as well.
Rename Channel_Count() to Channel_CountVisible() and only count channels
that are visible to the requesting client, so the existence of secret
channels is no longer revealed by using LUSERS.
Reported by Cahata -- thanks!
Unknown user and channel modes no longer stop the mode parser, but are
simply ignored. Therefore modes after the unknown one are now handled.
This is how ircd2.10/ircd2.11/ircd-seven behave, at least.
Reported by Cahata -- thanks!
This fixes:
irc-oper.c: In function ‘IRC_xLINE’:
irc-oper.c:429: warning: ‘class’ may be used uninitialized in this function
irc-oper.c:430: warning: ‘class_c’ may be used uninitialized in this function
Alexander Barton