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
