This matches the naming in STL, which is what we are mostly mimicing now
that we are using std::string for these functions.

It's just confusing that we have our own variety that isn't compatible.

It has now been replaced, mostly by std::string, so remove the actual
type definition.

Avoids a bit of complexity by delegating that handling to a string
object.

Let's use a more common type instead of something homegrown. Should be
more familiar to new developers.

It's more standard and familiar than our custom CharArray type, and it
still gives us automatic freeing of the buffer.

We could probably have used std::unique_ptr instead, but we are
currently targeting older compilers where C++11 isn't standard yet.

It's extreme overkill to inherit from CharArray just to get the
automatic freeing of the buffer when the object is destroyed.

Get rid of all the magical re-allocation and shuffling and instead just
return a new set of strings that is fully splitted. Will consume a bit
more memory, but is a lot safer to use as there is less confusion about
ownership of memory.

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.