LemonBoy
9160ddaffd
Keep processing the CAPs on error
...
If an invalid CAP is found we keep going by parsing the next one.
2018-01-07 12:36:20 +01:00
LemonBoy
cd107deb46
Prevent a memory leak
...
When a CAP DEL is received the key/val pair is not stored in the
hashtable at all so just free them when we're done.
2018-01-07 12:36:20 +01:00
LemonBoy
74409aa850
Miscellaneous fixes
...
Stylistic stuff, please ignore.
2018-01-07 12:36:20 +01:00
LemonBoy
f683e81880
Prevent a NULL pointer deference
...
Always create the cap_supported table when a CAP event is received.
2018-01-07 12:36:20 +01:00
LemonBoy
432368bdc6
Use strcmp instead of g_strcmp0
...
There's no need to use the latter.
2018-01-07 12:36:19 +01:00
LemonBoy
cfc8c9f8e2
Properly dispose the GSList chains
...
We forgot to free the link and the data, oops.
2018-01-07 12:36:19 +01:00
LemonBoy
f4d811ddf5
Handle CAP {ADD,DEL} from cap-notify
...
This is the last piece of the puzzle.
2018-01-07 12:36:19 +01:00
LemonBoy
8c87766132
Parse multiline responses to CAP LS
...
The parsing logic isn't too elegant because of the optional parameter
used for signaling if a response has a continuation one.
2018-01-07 12:36:19 +01:00
LemonBoy
d21706e1cc
Factor out the parsing function
...
This is also needed for CAP NEW and CAP DEL.
2018-01-07 12:36:18 +01:00
LemonBoy
98836f8b7e
Parse the K/V form in CAP LS
...
This is a prerequisite for the IRC v3.2 compliance.
2018-01-07 12:36:18 +01:00
dequis
82ce1de5b0
irc-cap: Don't send a space at the beginning of the CAP REQ parameter
...
Turns out it confuses inspircd, making it reply a NAK with empty
parameter. The rest is ACKed anyway. I've already whined at saberuk
and there's a pending pull request over there fixing this issue.
And, of course, this is cleaner.
2015-11-26 19:50:58 -03:00
LemonBoy
21c1e4e9f8
Fix two minor issues outlined in the PR#222
...
irc-cap.c has now a licence header.
A minor style fix in misc.c
2015-09-02 22:40:10 +02:00
LemonBoy
2d7030a844
Implement support for IRCv3.1 CAP negotiation
2015-05-05 23:14:26 +02:00