We mostly use classical C strings, but the memory management around them
can get confusing and error prone. Let's use std::string for the cases
where we need to return a newly allocated string.

The compiler doesn't enforce this, but it at least documents the
expected array size.

We know the needed space here, so let's keep it simple with a constant
size string buffer.

It should return a path to the directory itself, just like its sister
function getuserhomedir().

All library functions should be in a proper namespace.

A blank string might be very confusing, depending on where this will be
used. Let's give something more visible back in the cases where we
cannot get the proper name for the peer.

This mimics how some system functions (like inet_ntop()) work, and
avoids complexity around ownership of the returned string buffer.

The downside is that the string must be consumed directly as it will be
overwritten on the next call, but that is not an issue with the current
usage.

Use the same indentation we use in all other files.

These don't need to be changed, so let's just keep it simple with a
constant string literal.

It's unclear why this was initially added. The function takes string
constants, so it is not going to modify these.

Avoid complicating things by moving things in to a second buffer here as
there is no need for it.

We don't need to make extra copies of the string in most cases, so let's
simplify the code and access the string directly when we can.

We never use Windows' "UNICODE" mode anyway, so let's get rid of this
complexity.

This makes memory management more clear and robust when using these
helper functions.

Let the string helpers call the more fancy setParam(). This makes sure
we can avoid duplicating things.

Otherwise the old length is preserved, which will result in NULL pointer
dereferencing if the parameter is ever accessed.

This is explicitly a byte sequence, so let's try to keep a consistent
typing.

These are used here and there so let's make them more general rather
than hiding them in the stream classes.

Avoid our own custom types in favour of what's already included with
C++.

Avoid having our own custom stuff and instead use the modern, standard
types, for familiarity.

Avoid preprocessor magic and instead rely on templating to generate
optimized functions for performance critical code.

Everything else uses LF line endings, so fix up the few stray ones.

We might not have all the necessary information, e.g. all targets might
not exist yet, until we're done going through all CMakeLists.

They may be crucial, so refuse to continue if this happens.

This is what the linker does, so we should do the same for correct
behaviour.

Things might be in odd places, so make sure we respect where we're told
to look for libraries.

We have internal dependencies that should be respected, as otherwise it
will be up to the user of the .la file to figure out the correct order
of the libraries.

I think this only affects macOS at the moment where they also have .tbd
files for linking.

We don't really use the .la files for macOS at the moment, but let's try
to be prepared.

This serves no useful purpose as we have no reason to suspect there will
be a dangerous first character in these variables.

Not sure how the old one ever worked as it incorrectly just tried to
match last character and nothing else.

<target>_LIB_DEPENDS is an internal variable that contains lots of other
weird stuff.

These are supported by gcc and clang, and I don't think MSVC works well
with our code anyway, so let's keep things simple and use these
directly.

These are also useful warnings that tend to find real bugs, so let's
enable then.

The downside is they require us to mark certain things so the compiler
knows if they were on purpose or not.

That warning doesn't play well with Windows' GetProcAddress(), so add
some extra casting to work around it.

This isn't needed with modern build environments, and can even conflict
with them.

gcc will complain, and we will fill out all fields later anyway.

These types caused an incorrect signed/unsigned behaviour, so let's make
sure we use the appropriate type.

gcc can get upset if they aren't in this order.

If we don't mark these as volatile then they might get reset on
longjmp() and the code will misbehave.

These are just values, so setting const on them has no effect as the
caller will get a copy.

These are all truisms because of the valid range of the types.

This allows us to separate accidental fall through from explicit ones,
which allows us to turn on such checks in the compiler.

If there isn't enough data, then the client reading the hash will fall
down and try to read the subtype instead, which isn't correct.

Invert the logic so we get a more consistent way through where we only
break out when there is insufficient data.

Do the same for the server code, for consistency.

These were not meant to fall through. Likely didn't have any adverse
effects, but let's fix it anyway.

This allows us to separate accidentally unused, from explicitly unused
parameters, which allows us to turn on such checks in the compiler.