We use char *member_modes like we now have at all the other places,
which contains eg "o".
TODO: fix prefix sending rules or remove some if 0'd out code
And not sure if we want to do it entirely this way :D
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
1) All IRC clients support prefixes nowadays
2) People generally misunderstand the question and think this
disabled +q (channel owner) and +a (channel admin), when
in fact it does not. It only enables/disables the showing
of prefixes, and it changes some of the rules eg requiring
+qo / +ao for actions that normally only require +q / +a.
3) We now have the modularized +q and +a, so you can actually
disable channel owner and channel admin, which is what most
users want(ed) that previously disabled PREFIX_AQ.
For all users (95%+) that enable PREFIX_AQ there is no effective
change. For the other 5% it is likely only for the better.
sendnumeric_legacy() calls.
This also fixes some small format string bugs (eg: argument too much and
some time_t fun, like the previous commits elsewhere... nothing fancy).
an extra char **errmsg argument. Upon failure (non zero return value)
this should contain a format string to be sent to the client
(with the return value denoting the number of the numeric).
This gets rid of sendnumeric_legacy() in join.c
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.
I don't think there were more than a handful of people who disabled
this, and it clutters the source badly (not to mention that this
should not be a compile time option at all).
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 :)
- For HOOKTYPE_LOCAL_JOIN and HOOKTYPE_REMOTE_JOIN: drop parv[] argument
as it was useless anyway, it only contained the channel name in parv[1]
but never the key, sometimes was entirely NULL even.
- For HOOKTYPE_PRE_LOCAL_JOIN instead of char *parv[] we now pass
const char *key. As predicted more than a year ago when fixing
0902ed7a99
argument which specifies how many characters to copy max.
strlncpy(dest, src, sizeof(dest), maxcopybytes);
vs
strlcpy(dest, src, MIN(sizeof(dest),maxcopybytes+1));
We already had a strlncat() vs strlcat()
server where the client is (or was) on. Just like we did in UnrealIRCd 5.
Not sure if API-wise and variable-name-wise I want to do it this way,
but whatever...
Bram Matthys