This test is done quite a bit across the tree, and the open-coded variants make it easy to have an
accidental mismatch between the length of the prefix being tested and the length actually passed to
strncmp().
This fixes an issue of that type comparing the server version against the prefix "u2.10", where the old
code used an incorrect length of 4.
remove_channel() is only called in direct response to a message from a server,
so it always acts on from_server - remove the unnecessary server argument.
The channel argument is always non-NULL - remove the dead code that removed all
channels if a NULL channel was passed.
This FSET has existed for a long while but has been unused for some time,
since before the userlist was reworked to use flags instead of levels. This
means that the default value for the FSET also has to be updated.
Functions display_msg() and check_sync() are only used in numbers.c, so they
can be static.
Remove inclusions of <numbers.h> from .c files that don't need it.
Chatnet doesn't use the odd 310 numeric support anymore, it now uses 310 for
the same WHOIS_HELPFUL as Dalnet. They apparently use a pretty bog-standard
Unreal ircd now.
Integer division has potential edge-case overflow problems that are best avoided.
git-svn-id: svn://svn.code.sf.net/p/bitchx/code/trunk@536 13b04d17-f746-0410-82c6-800466cd88b0
(ERR_RESTRICTED), to set user mode +r - however this does not appear to
be necessary anymore. It was also buggy for several reasons: due to
a change in set_server_flag() this has actually been setting mode +G; and
484 is ERR_ISCHANSERVICE on other ircds.
git-svn-id: svn://svn.code.sf.net/p/bitchx/code/trunk@233 13b04d17-f746-0410-82c6-800466cd88b0
This includes all of the underlying support, but doesn't hook it up to the
/SERVER command yet, so it's not useable at this point.
git-svn-id: svn://svn.code.sf.net/p/bitchx/code/trunk@216 13b04d17-f746-0410-82c6-800466cd88b0
hybrid yet because it uses numeric 275, which clashes with unreal's RPL_STATSDLINE.
RIP dmr.
git-svn-id: svn://svn.code.sf.net/p/bitchx/code/trunk@144 13b04d17-f746-0410-82c6-800466cd88b0
This is numeric 716. Hybrid shows it in WHOIS, and both show it when you
try to PRIVMSG someone who is +g (similar to AWAY). So I've formatted it
to match the WHOIS block.
I also took the chance to fix up the ordering of the fsets, and remove
a bunch of redundant setting of default values.
git-svn-id: svn://svn.code.sf.net/p/bitchx/code/trunk@103 13b04d17-f746-0410-82c6-800466cd88b0
clearing last_away_msg when the 311 whois reply numeric is recieved.
git-svn-id: svn://svn.code.sf.net/p/bitchx/code/trunk@95 13b04d17-f746-0410-82c6-800466cd88b0
channel) are correctly rounded. Added a divide_rounded() function
that rounds to nearest integer. This also gets rid of the messy
floating point divisions in that function.
git-svn-id: svn://svn.code.sf.net/p/bitchx/code/trunk@73 13b04d17-f746-0410-82c6-800466cd88b0
get_server_name(from_server) instead of get_server_itsname(from_server) -
this meant that if the client had a different idea of the local server name
from the server (say, if you used a round-robin to connect), then the client
would incorrectly assume the numeric came from a remote server.
The symptoms were:
* If your local server sent you a "you're not op" type message, BitchX would
report the channel had desynched.
* If your local server send you a "channel doesn't exist" numeric (eg. if
you typed /mode #nosuchchannel to see if it existed), BitchX would not show
it.
git-svn-id: svn://svn.code.sf.net/p/bitchx/code/trunk@71 13b04d17-f746-0410-82c6-800466cd88b0
(bad password) that the client wasn't expecting.
The most common case is failing a CHALLENGE oper attempt.
git-svn-id: svn://svn.code.sf.net/p/bitchx/code/trunk@55 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
