src/modules/tkl.c is the main one).
Also move DB writing/reading functions to src/misc.c so they can be
removed out of channeldb and tkldb.
Important note to current tkldb users:
Unfortunately due to the major cleanup I had to remove upgrading
for previously saved tkl db files. That seemed not worth the effort
for maybe <15 current users or so. It also makes the tkldb code
a lot more cleaner. Otherwise it would be a huge mess.
Currently a FIXME item: spamfilter support in RMTKL.
and remove old dependency field (never used, was always NULL,
broken since 3.2.x)
I'll add some constraints later on things like names and versions.
IOTW: more changes to follow, don't mass update your own mods yet.
explicit cast to (long long). On *NIX we could get away with
lazily assuming time_t is of the same length as long (and use %ld),
even though the specification says nothing about it.
Unfortunately on Windows things are not that simple:
'time_t' is 'long long' (64 bits) and both 'int' and 'long'
are 32 bits, even when compiling in 64 bit mode.
This problem could be 'fixed' in multiple ways:
One way would be to minimize the usage of time_t and use 'long long'
or 'uint64_t' everywhere for variables to minimize casting later.
I, however, chose to maintain 'time_t' for most of time grabbing
and time calculations (eg: delta), and do the explicit cast in
any printf-like functions that may be there.
Both solutions work. I mostly like the explicit time_t look, so one
can immediately recognize a variable relates to time.
Make local spamfilter blocks use this too. Already did so for
ban xxx types that will cause kline/gline/zline and qline.
This also simplifies handling in the tkldb module.
If everything goes correctly then after reading all TKL entries we
should be at the end of file. If there is still data after that,
something went wrong... quite wrong.. :D
This, rather than having the module not loaded at all, which could mean,
especially if missed the warning on boot, that you run for weeks or
months without having your TKL's stored, which would be a shame ;)
Also a failure to rename() is not fatal, as it likely means that we
don't have permissions, in such a case you will see a repeated error
every X minutes due to the write, which is good.
Bram Matthys