C-toxcore: Don't include OS specific headers in .h files
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.
iphydf
All 5 comments
Sounds good
nurupo
on 12 Sep 2016
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.
iphydf
on 18 Dec 2016
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.
GrayHatter
on 30 Dec 2016
Not fully fixed
Diadlo
on 27 Jan 2017
@GrayHatter agreed. Let's have a single file implementing the OS specifics.
I'm unassigning @Diadlo for now. I think this is a great bug for new contributors to work on, as it gives exposure to much of the codebase and network code. It's a somewhat interesting refactoring that has no impact on functionality, so it's easier to test.
iphydf
on 16 Jan 2018
Related issues
DataMaster-2501
·
6Comments
MrSorcus
·
10Comments
iphydf
·
9Comments
zetok
·
3Comments
GrayHatter
·
3Comments
Most helpful comment
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.