While functionally compatible with the implementation in ElementalIRCd, our approach is different,
specifically pre-calculating the bitmask at config load time. This is more efficient, and allows us
to report errors as part of the configuration phase.
When receiving bans from a bursting server, if kline_delay is set to 0
(the default), rb_event_addonce will be called to schedule an event for
0 seconds in the future. While this works fine for the fallback
rb_event_run function, the epoll implementation ends up scheduling a
timerfd for the event in the past, which is then never executed.
While fixing this, I also made rb_event_add and rb_event_addonce reject
attempts to add events scheduled for 0 seconds in the future; they're
instead rewritten to run 1 second in the future.
s_assert requires some higher-level functionality that shouldn't be
present in ircd_defs.h. ircd_defs.h is used by ssld, which has no notion
of logging or sending IRC messages. Additionally, some of the headers
s_assert depends on result in conflicting definitions in ssld.c.
This change also fixes the compile when using --enable-assert=soft.
This was broken by 6f7b36d5d0 in February
2013, as join failures are the only situation where a non-trivial
numeric is passed through from other code to be sent to a client. Fix it
by porting more code from ircd-ratbox 3.1.
With this comes an example module to block the killing of services.
NOTE: this will not cancel remote kills. Those are still accepted, per
the TS 6 specification.
This will allow us to modularize message processing, e.g. having new modules to manipulate
channel and private messages in new ways.
Yes: it can be used to intercept messages, but such modules are already out in the wild for
charybdis anyway -- so this doesn't really change anything there.
If you are changing the text, then it is your responsibility to provide a pointer to a new
buffer. This buffer should be statically allocated and stored in your module's BSS segment.
We will not, and cannot, free your buffer in core, so dynamically allocated buffers will
cause a memory leak.
This will allow us to simplify m_message considerably, by moving channel mode logic out to
their own modules.
Arbitrarily prefer a forward channel to no forward channel and an
alphabetically higher forward channel to a lower one.
This is a simplistic implementation that generates one MODE message to
local clients for each ban removed (to be replaced).
For simplicity and to avoid amplification of incoming MODE messages,
regular modes may still desync the forward channel of a ban.
