eggdrop icon indicating copy to clipboard operation
eggdrop copied to clipboard

net-type bug

Open michaelortmann opened this issue 4 years ago • 0 comments

i didnt look up when exactly the bug was introduced. the problem is, when we do set (or change) net-type, eggdrop has two traces on that variable. one in irc.c, another one in server.c (2 different modules) whatever the first trace is, when it exits the trace functionwithout error, then net_type is set. net_type_int is another variable, set in the server.c trace usualy, the irc.c trace is executed before the server.c trace but the irc.c is the one, setting lots of internal variables in respect of the new/current net_type_int now, if we change net-type, irc.c doest see the new net_type_int this is a kinda serious bug, breaking our net-type handling completely, if im correct.

demo:

.set net-type efnet
Ok, set.

.set net-type efnet
Ok, set.

.set use-354
Currently: 0

.set net-type libera
Ok, set.

.set use-354
Currently: 0

.set net-type libera
Ok, set.

.set use-354
Currently: 1

we probably should try harder to only set one single trace function onto a variable to avoid such issues.

my first idea was, removing the trace in irc.c and exporting do_nettype() thru module API and then let the server.c trace call irc.c:do_nettype() instead.

but cant call from server.c into irc.c because irc mod depends on server.mod, thus when server.mod loads and executes its traces first, the irc mod isnt loaded yet.

michaelortmann avatar Oct 29 '21 21:10 michaelortmann