| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
This is much more robust and flexible than what we came up with.
|
|
|
|
|
| |
OS abstractions are generic enough that we can merge these with the new
core library.
|
|
|
|
|
| |
It's just string helper functions here, so let's get rid of the
catch-all name for this module.
|
|
|
|
|
|
|
|
| |
They weren't that well used, and were mostly just confusing special
functions anyway.
Allows us to move away from generic and ambigious headers such as
"util".
|
|
|
|
| |
Let's clear things up by categorizing our utility functions.
|
|
|
|
|
|
|
| |
Make it clearer what is protocol handling and what is just general
plumbing.
This is one step of several.
|
|
|
|
|
|
|
| |
Make it clearer what is protocol handling and what is just general
plumbing.
This is one step of several.
|
|
|
|
|
|
|
| |
Make it clearer what is protocol handling and what is just general
plumbing.
This is one step of several.
|
|
|
|
| |
Overlooked this special exception in the previous commit.
|
|
|
|
|
| |
This is required for the built in exceptions, so let's do the same to
avoid surprises.
|
|
|
|
|
|
| |
That type is not guaranteed to preserve anything useful at all. Instead,
try to either preserve a more specific type, or use std::runtime_error
which at least has a guaranteed message.
|
| |
|
| |
|
|\ |
|
| |
| |
| |
| | |
The reason for this is to keep a consistency through out the project.
|
| |
| |
| |
| |
| | |
This makes things more consistent since we mix with the standard library
exceptions so often.
|
| |
| |
| |
| |
| | |
There is no point to having our own generic exception class. Let's use
the one provided by the standard C++ library.
|
| |
| |
| |
| |
| | |
Use the more specific already included exception classes for common
errors to keep things more understandable.
|
| |
| |
| |
| |
| | |
Make sure our exceptions are part of the standard exception class
hierarchy.
|
| |
| |
| |
| | |
Harmonize with the standard C++ exceptions.
|
| |
| |
| |
| |
| | |
In preparation for using the built-in exception types, where the string
can only be set via the constructor.
|
| |
| |
| |
| |
| | |
In preparation for using the built in C++ exception classes, which do
not accept a format string.
|
|/
|
|
|
| |
These seem to always be in ASCII and English, unfortunately, but let's
at least use the API the could give use something more useful.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Windows has (at least) two error namespaces, both errno and
GetLastResult(). These overlap, so it is important we keep track of
which one we are dealing with.
To make things extra problematic, the BSD socket API normally uses
errno, but on Windows it has been mapped in to the GetLastResult()
namespace.
Try to keep better control of this by using separate classes for the
namespaces.
|
|
|
|
|
|
| |
The behaviour is not consistent as Windows doesn't use errno for socket
errors, but Unix systems do. Always use the same exception to keep
things somewhat sane.
|
|
|
|
|
|
| |
Socket APIs are used in more places than the abstraction in
common/network. Make it easier to use this exception class by putting
it in a more common place.
|
| |
|
|
|
|
|
| |
It's a source of confusion and possibly bugs to reuse the same variable
name for multiple things.
|
|
|
|
|
| |
Use the new "override" keyword to properly differentiate between new
virtual methods, and existing virtual methods being overridden.
|
|
|
|
|
| |
It's more readable than 0, and a bit safer than NULL, so let's try to
follow modern norms.
|
|\ |
|
| |
| |
| |
| |
| | |
These will always be byte streams at heart, so let's try to keep them
with a proper type. Should make it clearer how they will be used.
|
| |
| |
| |
| |
| | |
If we can't rely on the OS to handle corking for us, then we need to
enable our own handling of it.
|
| |
| |
| |
| |
| | |
It is more specific, and it properly sets up propagation when include
directories also need to be used further down a dependency chain.
|
|/
|
|
|
| |
This is important in case there are build flags that need to propagate
between libraries for things to build correctly.
|
|
|
|
|
|
| |
This can have unexpected consequences as some code may rely on it being
a simple variable. Instead to what we do in Socket, which is to define a
unique name for getting socket error numbers.
|
|
|
|
|
| |
We never use Windows' "UNICODE" mode anyway, so let's get rid of this
complexity.
|
|
|
|
|
| |
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.
|
|
|
|
|
|
| |
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.
|
|
|
|
|
| |
This allows us to separate accidentally unused, from explicitly unused
parameters, which allows us to turn on such checks in the compiler.
|
|
|
|
|
| |
This makes sure the compiler doesn't complain about problems in those
files.
|
| |
|
| |
|
|
|
|
|
| |
This call should have been preceeded by hasData() or avail(), just like
all other accessor functions.
|
|
|
|
| |
We should scope these as narrowely as possible to avoid side effects.
|
|
|
|
|
|
| |
Avoid duplicating all the memory mangement, and instead use the
BufferedOutStream as a base clase for all out streams that need an
intermediate buffer.
|
|
|
|
|
| |
Allow subclasses to call it, instead of it being strictly internal. This
is useful when a subclass can only provide data in minimum sized chunks.
|
|
|
|
|
|
|
|
|
|
|
|
| |
These streams both need to change the corking state temporarily, but it
is important it is restored to the previous state or things might get
messed up.
For the zlib stream it would just leave things uncorked, which still
works but is less efficient.
But for the TLS stream it might make things very unresponsive as the
corking might be left on permanently, delaying packets indefinitely.
|