Don't include OS specific headers in .h files

[iphydf]

Currently, network.h includes a whole lot of platform specific headers (like u.h, windows.h, and unistd.h). We should confine these to a single file (or a few files).

I suggest we create a thin abstraction on the OS facilities for networking, and another on the ones for the monotonic clock. We could then have one file per platform kind (e.g. ${module}_win32.c, _unix.c, _osx.c, _posix.c, ...) and conditionally compile them according to preprocessor symbols, just like we do already. The downside is that it's a little bit more declaration overhead, because currently those #ifdefs are inside functions that will need to be redefined for each platform. The advantage is that there are no or few #ifdefs in the code itself, and the platform specific code is in a set of small files instead of (as it is now) in a 1100 line file mixing platform abstractions with application code.

[nurupo]

Sounds good

[iphydf]

How about we make a "system" interface that can be implemented by a "windows system" and a "posix system" and a "test system"? The test system could be used in unit tests and simulates a system without actually doing system calls.

[GrayHatter]

I disagree on the implementation suggestion. I'd much rather see all functions in a single file {network,time,...}.c, with #ifdefs used to wrap functions that need to be written differently for each platform.

The benefits of this method over separate files, is that we can force all platform specific code as a static function, and expose a single API for the higher levels of toxcore. Any platform implementation details will be easily viewable from a single file. Platform peculiarities will require abstraction, and handling within a single file, instead of across multiple files. It will also make the cmakelists.txt file easier to maintain (It's already starting to get away from us.) And later review, with our current review system.