A queued CSET is one that is set before the matching channel is joined. The CSetList is allocated and linked to
the cset_queue list.
The use-after-free bug was caused because the CSetList wasn't removed from the cset_queue after it was attached
to a joined channel. If the channel is parted, it eventually ages out of the Whowas-Chan-List and the CSetList
is freed, but there is now a dangling pointer to it in the cset_queue. This is fixed by removing the CSetList
from the cset_queue when it is attached to a channel, so the net result of /CSET #chan ; /JOIN #chan is the same
as doing the reverse.
Queued wildcard CSETs never worked properly - the queued CSET with the wildcard name would end up attached to any
subsequent matching channel that was joined. Channel names with wildcards in them are legal anyway, so the best
medium-term solution (pending a full redesign of the whole CSET command) is to just enforce that queued CSETs are
always literal channel names, not wildcards.
This fixes a bug where the cached channel log level bitmask was not correctly set unless you did a
/cset CHANNEL_LOG_LEVEL after the channel had been joined, which resulted in most things not being
logged.
It makes most sense to cache the bitmask within the cset structure, and there was even an (ununsed)
field already there for it.
git-svn-id: svn://svn.code.sf.net/p/bitchx/code/trunk@512 13b04d17-f746-0410-82c6-800466cd88b0
like x86-64, where sizeof(int) != sizeof (void *). This involves correctly
casting every function pointer from the global table to the correct
function type, which has the added benefit of allowing type-checking of
function arguments and return values.
git-svn-id: svn://svn.code.sf.net/p/bitchx/code/trunk@26 13b04d17-f746-0410-82c6-800466cd88b0
