These macros all interact with the result code type, so they should
ideally be within this file as well, so all the common_funcs machinery
doesn't need to be pulled in just to use them.
`network.cpp` has several error paths which either:
- report "Unhandled host socket error=n" and return `SUCCESS`, or
- switch on a few possible errors, log them, and translate them to
Errno; the same switch statement is copied and pasted in multiple
places in the code
Convert these paths to use a helper function `GetAndLogLastError`, which
is roughly the equivalent of one of the switch statements, but:
- handling more cases (both ones that were already in `Errno`, and a few
more I added), and
- using OS functions to convert the error to a string when logging, so
it'll describe the error even if it's not one of the ones in the
switch statement.
- To handle this, refactor the logic in `GetLastErrorMsg` to expose a
new function `NativeErrorToString` which takes the error number
explicitly as an argument. And improve the Windows version a bit.
Also, add a test which exercises two random error paths.
Now that clang-format makes [[nodiscard]] attributes format sensibly, we
can apply them to several functions within the common library to allow
the compiler to complain about any misuses of the functions.
These are unused and essentially don't provide much benefit either. If
we ever need rotation functions, these can be introduced in a way that
they don't sit in a common_* header and require a bunch of ifdefing to
simply be available
Android and macOS have supported thread_local for quite a while, but
most importantly is that we don't even really need it. Instead of using
a thread-local buffer, we can just return a non-static buffer as a
std::string, avoiding the need for that quality entirely.
__forceinline is a MSVC extension, which may confuse some people working on the codebase.
Furthermore, the C++ standard dictates that all names which contain adjacent underscores are reserved.
When the macro was introduced in 326ec51261
it wasn't noticed that it conflicted in name with a heavily used macro
inside of dyncom. This causes some compiler warnings. Since it's only
lightly used, it was opted to simply remove the new macro.
