| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
| |
It's a source of confusion and possibly bugs to reuse the same variable
name for multiple things.
|
| |
|
|
|
| |
It's more readable than 0, and a bit safer than NULL, so let's try to
follow modern norms.
|
| |
|
|
|
|
|
|
|
| |
They must belong to the rfb namespace, not to the SConnection class.
Also add an AccessNone constant, since it's better to use a mnemonic
symbol rather than zero to initialize the accessRights members.
Signed-off-by: Carlos Santos <casantos@redhat.com>
|
| |
|
|
|
|
| |
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.
|
| |
|
|
|
| |
It's perfectly safe to delete NULL pointers, so simplify things by
removing these checks.
|
| |
|
|
|
| |
There is already an implicit connection between them, so let's make
it explicit. This allows easy lookup outside of the processMsg() function.
|
| |
|
|
|
|
| |
Both SSecurityVeNCrypt and SSecurityStack are wrappers around other
security objects, so they need to delegate the properties of those
sub-objects properly.
|
|
|
TLSNone and TLSVnc VeNCrypt subtypes are implemented.
git-svn-id: svn://svn.code.sf.net/p/tigervnc/code/trunk@4045 3789f03b-4d11-0410-bbf8-ca57d06f2519
|
