| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
| |
It's a type specific to that class, so let's keep them close for
clarity.
|
|
|
|
|
| |
It is much more natural than custom methods for this very common
operation.
|
|
|
|
|
|
| |
It is easy to get confused if these methods modify the existing object,
or return a new one. So let's mark the return value as critical so the
compiler can help out if someone gets it wrong.
|
|
|
|
| |
It doesn't use any exceptions, so stop including the header for it.
|
|
|
|
|
|
|
|
| |
These files don't use anything from this header, so remove the include.
This exposes some missing includes in other places, though. So add an
explicit include in the files that were relying on an indirect
inclusion.
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
| |
It's unclear why this was initially added. The function takes string
constants, so it is not going to modify these.
|
|
|
|
|
| |
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.
|
|
|
|
|
|
| |
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.
|
|
|
|
|
| |
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.
|
|
|
|
|
| |
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.
|
|
|
|
|
| |
This allows us to separate accidentally unused, from explicitly unused
parameters, which allows us to turn on such checks in the compiler.
|
|
|
|
| |
They have no need for it, so let's simplify things.
|
|
|
|
| |
Everything in flags is already handled at a higher level.
|
|
|
|
| |
The flags should always be empty anyway.
|
|
|
|
|
| |
This makes sure the compiler doesn't complain about problems in those
files.
|
| |
|
| |
|
|
|
|
|
|
| |
We don't want any stray exceptions as we are cleaning up, so handle any
still pending decoder errors by just logging them. We are already
shutting down so there is no need to abort the connection here.
|
|
|
|
|
|
| |
These require a key to have been set up on the server beforehand, so
they do not give a good default experience as clients will be unable to
connect.
|
|
|
|
| |
This is to make the code more tolerant of typos when entering a hostname
|
| |
|
| |
|
|
|
|
| |
We should scope these as narrowely as possible to avoid side effects.
|
| |
|
|
|
|
|
|
|
|
|
| |
Avoid having to buffer everything we want to discard, and instead do it
piece by piece. This is more efficient, and avoids hitting any limits on
the buffering.
Note that this is safe here because we already know we have all the
compressed data. It would not be safe for a general input stream.
|