Fix traffic counter for transfer.mod in

[michaelortmann]

Found by: https://github.com/michaelortmann/
Patch by: https://github.com/michaelortmann/
Fixes:

One-line summary:
Fix traffic counter for transfer.mod in

Additional description (if needed):

Test cases demonstrating functionality (if applicable):
On the Bot:
.chattr testuser +x
On the shell of testuser:

> wc -c testfile
2679080 testfile
>>> 2679080 / 1024 / 1024
2.5549697875976562

which means testfile is 2.55 MB
on the irc client of testuser:
/dcc send Bot testfile
Before:

.traffic
[...]
Transfer.mod:
  out: 656 Bytes (656 Bytes today)
   in: 4.10 KBytes (4.10 KBytes today)

After:

.traffic
[...]
Transfer.mod:
  out: 656 Bytes (656 Bytes today)
   in: 2.55 MBytes (2.55 MBytes today)

This is not only a fix of traffic counting. if you create / send a file to the bot, that does not contain a NULL-byte, strlen(buf) would over read:
> valgrind --track-origins=yes ./eggdrop -t BotB.conf

[05:27:49] DCC connection: SEND testfile2 (michael!~michael@localhost)
05:28 < mortmann> ==516730== Conditional jump or move depends on uninitialised value(s)
05:28 < mortmann> ==516730==    at 0x48D1D78: strlen (vg_replace_strmem.c:506)
05:28 < mortmann> ==516730==    by 0x403714F: mainloop (main.c:783)
05:28 < mortmann> ==516730==    by 0x4038305: main (main.c:1223)
05:28 < mortmann> ==516730==  Uninitialised value was created by a stack allocation
05:28 < mortmann> ==516730==    at 0x4036F13: mainloop (main.c:727)
05:28 < mortmann> ==516730== :)

[michaelortmann]

Should / must we replace all traffic counter strlen(buf) with i (the returned len from sockgets())?

[thommey]

FORK_SEND and GET are also binary, right? they could use the same fix

[michaelortmann]

FORK_SEND and GET are also binary, right? they could use the same fix

outgoing binary traffic for GET is counted with variable otraffic* in net.c instead if itraffic*

now that i looked at the code again... sockgets() already returns strlen() for nonbinary data and the len for binary data, so in main.c traffic counting can be simplified...

[michaelortmann]

ready for review again

[thommey]

nice fix