Build the same message but send it to the local client first,
so that the echo-message capability works. But don't do it when
sending a message to yourself.
[ircd/match.c:316]: (error) Shifting a negative value is undefined behaviour
[librb/src/patricia.c:55]: (error) Shifting a negative value is undefined behaviour
[modules/m_alias.c:64]: (portability) '(void*)message' is of type 'void *'. When using void pointers in calculations, the behaviour is undefined.
[modules/m_time.c:111]: (warning) %u in format string (no. 9) requires 'unsigned int' but the argument type is 'signed int'.
[modules/m_time.c:111]: (warning) %u in format string (no. 10) requires 'unsigned int' but the argument type is 'signed int'.
[librb/src/dictionary.c:819]: (warning) %d in format string (no. 3) requires 'int' but the argument type is 'unsigned int'.
[librb/src/radixtree.c:1080]: (warning) %d in format string (no. 3) requires 'int' but the argument type is 'unsigned int'.
[ircd/s_user.c:351] -> [ircd/s_user.c:357]: (warning) Either the condition '0!=source_p' is redundant or there is possible null pointer dereference: source_p.
[extensions/ip_cloaking_3.0.c:109]: (warning, inconclusive) The buffer 'buf' may not be null-terminated after the call to strncpy().
[ircd/chmode.c:256]: (style) Clarify calculation precedence for '&' and '?'.
[modules/m_help.c:100]: (style) Clarify calculation precedence for '&' and '?'.
[modules/m_knock.c:169]: (style) Clarify calculation precedence for '&' and '?'.
[modules/m_stats.c:628]: (style) Clarify calculation precedence for '&' and '?'.
[modules/m_stats.c:727]: (style) Clarify calculation precedence for '&' and '?'.
[librb/src/radixtree.c:601]: (style) Clarify calculation precedence for '&' and '?'.
[librb/src/radixtree.c:704]: (style) Clarify calculation precedence for '&' and '?'.
[librb/src/radixtree.c:739]: (style) Clarify calculation precedence for '&' and '?'.
[librb/src/radixtree.c:763]: (style) Clarify calculation precedence for '&' and '?'.
[librb/src/radixtree.c:768]: (style) Clarify calculation precedence for '&' and '?'.
[librb/src/radixtree.c:774]: (style) Clarify calculation precedence for '&' and '?'.
[librb/src/radixtree.c:781]: (style) Clarify calculation precedence for '&' and '?'.
[librb/src/radixtree.c:786]: (style) Clarify calculation precedence for '&' and '?'.
[librb/src/radixtree.c:791]: (style) Clarify calculation precedence for '&' and '?'.
[librb/src/radixtree.c:804]: (style) Clarify calculation precedence for '&' and '?'.
[ircd/wsproc.c:372]: (style) Unused variable: len
[modules/core/m_modules.c:382]: (style) Unused variable: i
[modules/m_stats.c:741]: (style) Unused variable: amsg
[ircd/authproc.c:390]: (style) Unused variable: iter
[ircd/authproc.c:391]: (style) Unused variable: client_p
The CHALLENGE functionality will set opername but not privset --
if an oper performs a WHOIS on someone currently half-way through
a challenge we will perform a NULL dereference.
Related to ircd-seven commit d7b05f7583babf6
This is a FIX FOR A SECURITY VULNERABILITY. All Charybdis users must
apply this fix if you support SASL on your servers, or unload m_sasl.so
in the meantime.
There are two important caveats here, however:
1) Aliased commands have more than 8 parameters will be truncated;
there's nothing I can do about this.
2) Parameters with colons will not be handled as you expect. Again,
nothing I can do about this.
This also lays the groundwork for the netjoin batch type, but that isn't
implemented yet. I don't like how some of this is implemented but it'll
have to do for now...
Compile tested, needs more testing.
It's a bit of a hack, but better than before. Rather than rehashing
(which could get us into an endless loop), we now segregate the
configuration phase (creating entries ircd-side in case we restart authd
later) and sending phases (when configure_authd() is called). Since we
have to call configure_authd() no matter what (to send timeouts etc.)
and we have to send this data to configure authd anyway, and sending
duplicate data is bad, this is the only way I can think of for now.
It seems to come from an era where long long didn't exist and 64-bit
machines weren't common. 32-bit machines are still common but I can't
imagine this will have much performance impact there.
This "fixes" #179 in title only, but see comments within.
There's no reason to really have these in the main ircd anymore, static
modules are dead and aren't coming back.
To ensure people don't do something hopelessly retarded, this is a core
module.
