| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
| |
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.
|
| |\ |
|
| | |
| |
| |
| | |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
| |
It's more readable than 0, and a bit safer than NULL, so let's try to
follow modern norms.
|
| |
|
|
|
| |
Avoid having our own custom stuff and instead use the modern, standard
types, for familiarity.
|
| |
|
|
|
| |
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.
|
| |
|
|
|
|
| |
The generally recommended way is to include it from source files, not
headers. We had a mix of both. Let's try to be consistent and follow the
recommended way.
|
| |
|
|
|
|
|
|
|
|
| |
Major restructuring of how streams work. Neither input nor output
streams are now blocking. This avoids stalling the rest of the client or
server when a peer is slow or unresponsive.
Note that this puts an extra burden on users of streams to make sure
they are allowed to do their work once the underlying transports are
ready (e.g. monitoring fds).
|
| |
|
|
|
| |
Most streams are backed by a memory buffer. Create common base classes
for this functionality to avoid code duplication.
|
| |
|
|
|
| |
Makes it more readable to write code that needs to know how much
data/space is available in a stream.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
We use a lot of lengths given to us over the network, so be more
paranoid about them causing an overflow as otherwise an attacker
might trick us in to overwriting other memory.
This primarily affects the client which often gets lengths from the
server, but there are also some scenarios where the server might
theoretically be vulnerable.
Issue found by Pavel Cheremushkin from Kaspersky Lab.
|
| |
|
|
|
|
|
|
| |
Provides safety against them accidentally becoming negative because
of bugs in the calculations.
Also does the same to CharArray and friends as they were strongly
connection to the stream objects.
|
| | |
|
| |
|
|
|
| |
Either by casting, or switching to a more appropriate type
for the variable.
|
|
|
More changes will follow.
git-svn-id: svn://svn.code.sf.net/p/tigervnc/code/trunk@589 3789f03b-4d11-0410-bbf8-ca57d06f2519
|
