later fd_close() call. This also removes fd_map() since fd_open w/FDCLOSE_NONE
now does that.
* If you use fd_socket() or fd_accept(), then no change.
When fd_close() is called we call close() on *NIX and closesocket() on Win.
* If you use fd_fileopen(), then no change.
When fd_close() is called we will call close() on both *NIX and Win.
* If you used fd_open() and then fd_unmap() because you didn't want us
to close the socket, then use fd_open() with FDCLOSE_NONE and
just call fd_close() instead of fd_unmap().
We will not actually close the fd in fd_close() (FDCLOSE_NONE).
* If you called fd_open() with other intentions then either specify a
FDCLOSE_SOCKET / FDCLOSE_FILE as the last argument, or more likely:
don't use fd_open() at all and use fd_socket() or fd_fileopen() instead.
For reasons on this change, see previous patch. This way is more sane and
makes it harder to make mistakes even beyond Windows-specific issues.
This fixes a file descriptor leak in Windows that happened in the
logging code. The most visible effect of this was if you had a
log::maxsize set then on Windows you would see:
"Max file size reached, starting new log file"
Every other line, forever (and not actually starting a new log).
fd_close() previously did not close the file descriptor of a file
on Windows because on Windows it needs to call close() for a file
and closesocket() for a socket, and it always did the latter.
On *NIX it's more easy and you can just always close() any fd.
this will currently produce a lot of warnings with -Wall.
- Fixed 159 of 184 warnings detected by the above, the other warnings are false.
Most warnings had to do with long vs int, and thus the format strings (%d->%ld)
or the vars (int->long) have been changed (many of these were time_t/TS vs int).
Only a few rare crashbugs were discovered.
- Module coders: for HOOKTYPE_LOCAL_CHANMODE the 'sendts' parameter was changed
from type 'int' to 'time_t', while in most circumstances (like on ia32)
you won't notice, I suggest you to update your callback functions anyway.
- Possibly fixed an issue with set::modes-on-join and mode +f, it could have
set random remove-chanmode times in the default chanmode line.
Bram Matthys