-
The TOPIC command can have two additional timestamps, one for the channel creation time and one for the last modification time of the topic. According to the sources the timestamp will be parsed into the time_t variable "ts" which will be given over to the do_settime() function that finally changes the topic and sends the change around.
If you only specify the channel creation timestamp but...
2009-11-13 23:58:58 UTC by g3rrlt
-
Indeed, I can confirm this. It doesn't require the server to not have any channels, either.
Looking at the code, it definitely looks like we're not null-terminating `buf` before sending it to send_reply(), for one thing.
2009-11-12 05:34:32 UTC by r33d
-
IMHO a clean solution would be expiring invites which exceed the hard limit (MAXCHANNELSPERUSER*10 or something like that) after 5 minutes.
Or even better, the code could be changed not to count invites from +k services - then you could get 50 or even more invites from a service but still only 20 from users.
2009-11-11 11:47:46 UTC by thiefmaster
-
When using NAMES 0 on a server which doesn't have any channels, the reply contains data looking like uninitialized memory.
2009-11-10 15:03:47 UTC by thiefmaster
-
dvdhrm's right. There should probably be some limit that floats slightly above the number of channels that the operator is currently in.
2009-10-11 16:38:19 UTC by entrope
-
The epoll function engine_set_events() generates an ET_ERROR event on the socket if the epoll_ctl() function call fails. If the socket belongs to a user, this will result in a call to exit_client(). This, however, will send data over the socket, thus indirectly calling send_buffer() which itself again indirectly uses engine_set_events() and hence will produce a stack-overflow due to an endless...
2009-10-07 20:50:39 UTC by dvdhrm
-
This would be a serious memory leak in the daemon. A user could simply invite the oper to thousands of channels and the invites won't get deleted. However, you may set an hard-limit to something higher than MAXCHANNELSPERUSER.
2009-09-21 10:07:06 UTC by dvdhrm
-
and add && !IsChannelService(cptr) too, in fact, you should excempt anything that is not bound to the maxchan limit.
2009-09-20 11:28:40 UTC by key2peace
-
Make that:
if ((int)(cli_user(cptr))->invites >=
feature_int(FEAT_MAXCHANNELSPERUSER) && !is_oper(cptr) && !IsChannelService(cptr))
Channelservices also should not have a limit :)
2009-09-20 11:23:27 UTC by key2peace
-
During checking the autoinvite feature an ircop/csc member pointed out that certain invites where missing, trying to track down the issue I found the following in the current svn code that might be the reason:
78 if ((int)(cli_user(cptr))->invites >= feature_int(FEAT_MAXCHANNELSPERUSER))
79 del_invite(cptr, (cli_user(cptr))->invited->value.chptr);
Since ircops are not bound to...
2009-09-20 11:18:00 UTC by key2peace
