These were not a surprise, but deliberate: we let the previous
clang-format commit be 100% clang-format job (so reproducable)
and after that we planend and did this commit, because we chose
to leave some stuff alone and do it manually.
This commit will (also) be added to .git-blame-ignore-revs
This reformats entire UnrealIRCd source code, according to
.clang-format which was previously commited.
This is reproducable using clang-format version 21.1.8.
These are only visual changes, they have no effect on code.
This commit will be added to .git-blame-ignore-revs so 'git blame'
and the similar blame view on GitHub will ignore this commit.
This mainly affects MODE #channel +vhoaq and such. And as with all these
optimizations it mostly affects channels with more than 10 people (eg
hundreds or thousands).
Also did add_member_mode() and del_member_mode() but those are not
used by our own code because we always use fast versions anyway.
Oh yeah and the +D invisibility shit via set_user_invisible():
that one i didn't benchmark but should be better as well for
large channels.
Only downside is that mtags would be NULL, but we don't use it in
cmd_uid() so that's okay. This saves us from generating mtags in
do_cmd() when we don't need it. And also a command handler lookup
and all that. Saves around 8% of unrealircd CPU for 100k connects.
Several notes:
* This only checks on-JOIN (not on nick change, message, etc)
for performance reasons
* If the #channel in ~inherit:#channel also contains ~inherit
entries then those are not processed (no recursion and no looping)
* Only a limited number of ~inherit entries is permitted.
This will be moved to set:: items in a future commit so you
can set different amounts for +b/+e/+I ~inherit.
* This is work in progress, UnrealIRCd or the entire world could explode
* Documentation will follow later
Developers:
* Sadly, clean_ban_mask() needed to be changed to have two more
parameters, 'ban_type' and 'channel' were added at different positions.
This because the module needs the ban type (EXBTYPE_BAN, EXBTYPE_EXCEPT,
EXBTYPE_INVEX) and channel because it rejects based on number of
existing ~inherit entries in the channel... and while is_ok() is called
for local clients and has all this information, for services clients
is_ok() is not called so the only way to reject the +beI is through
xxx_conv_param() which comes from clean_ban_mask().
It is now possible to override some set settings per-security group by
having a set block with a name, like `set unknown-users { }`
* You could use this to set more limitations for unknown-users:
```
set unknown-users {
max-channels-per-user 5;
static-quit "Quit";
static-part yes;
}
```
* Or to set higher values (higher than the normal set block)
for trusted users:
```
security-group trusted-bots {
account { BotOne; BotTwo; }
}
set trusted-bots {
max-channels-per-user 25;
}
```
* Currently the following settings can be used in a set xxx { } block:
set::auto-join, set::modes-on-connect, set::restrict-usermodes,
set::max-channels-per-user, set::static-quit, set::static-part.
a bug when two servers merge, you could see +beI items being set that
already exist, if the timestamp or setter differed between servers.
Now they are updated but no +beI is shown.
https://bugs.unrealircd.org/view.php?id=5681
instead of the server executing the MODE. Eg unrealircd.org/userhost
was set. This occured because the client = &me; was done after
the message tag preparation, now moved up so it's done before.
This is only for calls within the same module, as otherwise you
should use do_cmd().
Benefit of this way is that it is short and you don't have to worry
about passing the right command parameters, which may change over time.
Example as used in src/modules/nick.c:
- cmd_nick_remote(client, recv_mtags, parc, parv);
+ CALL_CMD_FUNC(cmd_nick_remote);
Pretty much everywhere we had:
0001 userhost_changed(client);
0002 if (MyUser(client))
0003 sendnumeric(client, RPL_HOSTHIDDEN, client->user->virthost);
Lines 2-3 are now integrated in userhost_changed().
Also fix two issues with CHGHOST in make_oper():
* if user was -x, modes had +x and a vhost, it would send the cloaked
host in the original vhost, while it should have been the real host
* if user was -x and went +x without vhost (so only uncloaked to cloaked)
then no CHGHOST message was sent at all
This existed in UnrealIRCd 3.2.x but was later removed when
switching to the new operclass system.
Requested by Valware in https://bugs.unrealircd.org/view.php?id=6041
Syntax: SVSO <uid|nick> <oper account> <operclass> <class> <modes> <snomask> <vhost>
All these parameters need to be set, you cannot leave any of them out,
HOWEVER some can be set to "-" to skip setting them, this is true for:
<class>, <modes>, <snomask>, <vhost>
In UnrealIRCd the <operclass> will be prefixed by "services:" if not already
present. It is up to you to include or omit it.
If you want to set any swhoises you need to use the SWHOIS s2s command,
other than that this command basically does everything for you,
in fact it uses the same code as the OPER command does.
Most of the "user is now ircop" code has been moved out of cmd_oper() to
a new function make_oper() that is called by both cmd_oper() and cmd_svso().
This function also changes the hook HOOKTYPE_LOCAL_OPER:
It no longer passes a ConfigItem_oper struct, since we can't do that for
remote opers. Instead it passes oper name and oper class.
The complete definition is now:
int hooktype_local_oper(Client *client, int add, const char *oper_block, const char *operclass);
UnrealIRCd 6 server would expand it into two different mode lines
with IDENTICAL msgid values. Obviously message ids must be different
for different events.
Introduced by b078a9c8b5.
using mixed UnrealIRCd 5 and UnrealIRCd 6 networks.
This is a slightly complex rewrite of make_mode_str() and do_mode(),
as we nog go from single mode lines to potentially multiple mode lines.
In short: whenever we would be near buffer cut-off point (the famous
512 byte limit) then previously we would prevent the mode, though not
succesfully in all cases where a network consists of mixed 5.x and 6.x.
From this point onward we no longer do that. Instead we convert one
MODE command to two MODE lines if that is needed.
The benefit of this is that we no longer prevent it BEFORE processing
the MODE, which is a flawed method and could be wrong (causing desyncs).
And also, we no longer partially ignore MODE lines from clients when
they would cause the limit to be exceeded, as we replace them with
two MODE lines instead.
These are more changes than I wanted at such a late point but.. they seem
to be necessary to prevent U5-U6 compatibility issues.
It's usage would be rare, but this is f.e. used from channeldb.
Other uses may be in some 3rd party module.
Example: set_channel_mode(channel, "+k", "key")
* Now ban_check_types (previously checktype):
this is one or more of BANCHK_* OR'd together, eg BANCHK_JOIN, BANCHK_MSG..
* Now ban_type (previously what2):
this is the type of the ban, eg EXBTYPE_BAN, EXBTYPE_EXCEPT, etc.
* Now is_ok_check (previously is_ok_checktype)
this is one of EXBCHK_* for is_ok, eg EXBCHK_PARAM to check parameter.
and used for auditting purposes across servers (assuming the servers
itself can be trusted).
This is done via the 'operlogin' module which is loaded by default.
Obviously for opers of U5 and below this information is not available.
This also changes the HOOKTYPE_LOCAL_OPER hook to include oper block info:
-int hooktype_local_oper(Client *client, int add);
+int hooktype_local_oper(Client *client, int add, ConfigItem_oper *oper_block);
joins in such a case, code was wrong (things being done in the wrong
scope).
This also fixes a bug where an OperOverride message was generated
for SAJOIN nick @#test
This already found a few issues.
As a side-effect, this also means you can only use RPL_xxx and
ERR_xxx in the 2nd argument from now on. You can no longer use
a dynamic integer (eg 'reply') at runtime, since then the format
string cannot be checked.
More to follow, after making sure it works on Windows too.
It means you can no longer modify eg parv[1] in-place with strtoken and such.
The main reason for this is that as a command handler you have no idea
where the arguments may come from. It could be from a do_cmd() with
read-only storage (eg a string literal) and so on.
It started with an experiment of how far I could get and how annoying the
side-effects would be, but they seem to be quite managable, so I'm
committing this stuff.
Hopefully this catches/solves some stupid bugs somewhere :)
do_mode_char_list_mode() and do_mode_char_member_mode(), which are
two quite different things.
And rewrite do_mode_char_member_mode() to get rid of switch/case
style and the goto.
Also add do_mode_char_write() which is used at 5 places (could be
expanded, probably).
* channel->mode.extmode to channel->mode.mode
* channel->mode.extmodeparams to channel->mode.mode_params
This because all channel modes that are set there are extended channel
modes, only lists are still in core atm and they never get set here.
Bram Matthys