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.

Avoid having our own custom stuff and instead use the modern, standard
types, for familiarity.

Implements support in both client and server for the extended
clipboard format first seen in UltraVNC. Currently only implements
text handling, but that is still an improvement as it extends the
clipboard from ISO 8859-1 to full Unicode.

We now filter incoming data, which means we can start assuming the
clipboard data is always null terminated. This allows us to clean
up a lot of the internal handling.

This is a lot safer and cleaner. The old code had a fixed size that
we didn't properly keep track of.

Make sure all methods only write what is given as arguments, and
avoid side effects by getting data from parameter objects. This keeps
things readable in the calling code.

We need to track different things in the server and client, so
separate things to two independent structures to keep things more
clear.

The handler is for incoming data and we should not be abusing that
class for the writer class. Do proper write prototypes for the
relevant functions.

As a result we weren't overloading properly.

This adds the basic infrastructure and handshake for the QEMU
Extended Key Events extension. No viewer or server makes use of
the extra functionality yet though.

InputHandler declares the second parameter of clientCutText
as an int.

Fixes:

/home/shade/dev/tigervnc/common/rfb/CMsgWriter.h:60:18: error: 'rfb::CMsgWriter::clientCutText' hides overloaded virtual function [-Werror,-Woverloaded-virtual]
    virtual void clientCutText(const char* str, rdr::U32 len);
                 ^
/home/shade/dev/tigervnc/common/rfb/InputHandler.h:36:18: note: hidden overloaded virtual function 'rfb::InputHandler::clientCutText' declared here: type mismatch at 2nd parameter ('int' vs 'rdr::U32' (aka 'unsigned int'))
    virtual void clientCutText(const char* str, int len) {}
                 ^

Clang doesn't like when struct and class are used to refer
to the same thing interchangeably.

Fixes all instances of:

In file included from /home/shade/dev/tigervnc/common/rfb/CConnection.cxx:29:
In file included from /home/shade/dev/tigervnc/common/rfb/CConnection.h:28:
/home/shade/dev/tigervnc/common/rfb/DecodeManager.h:35:3: error: class 'Exception' was previously declared as a struct [-Werror,-Wmismatched-tags]
  class Exception;
  ^
/home/shade/dev/tigervnc/common/rdr/Exception.h:32:10: note: previous use is here
  struct Exception {
         ^
/home/shade/dev/tigervnc/common/rfb/DecodeManager.h:35:3: note: did you mean struct here?
  class Exception;
  ^~~~~
  struct
/home/shade/dev/tigervnc/common/rfb/DecodeManager.h:43:3: error: class 'Rect' was previously declared as a struct [-Werror,-Wmismatched-tags]
  class Rect;
  ^
/home/shade/dev/tigervnc/common/rfb/Rect.h:68:10: note: previous use is here
  struct Rect {
         ^
/home/shade/dev/tigervnc/common/rfb/DecodeManager.h:43:3: note: did you mean struct here?
  class Rect;
  ^~~~~
  struct

The connection object is a much more appropriate object for the
decoders and encoders to keep track of. Besides the streams, it also
contains state like connection parameters.

We have no need for this abstraction so let's keep things simple.

git-svn-id: svn://svn.code.sf.net/p/tigervnc/code/trunk@4801 3789f03b-4d11-0410-bbf8-ca57d06f2519

git-svn-id: svn://svn.code.sf.net/p/tigervnc/code/trunk@4798 3789f03b-4d11-0410-bbf8-ca57d06f2519

git-svn-id: svn://svn.code.sf.net/p/tigervnc/code/trunk@3711 3789f03b-4d11-0410-bbf8-ca57d06f2519

This avoids big buffer overflow when memcpy is called with "-1" argument.


git-svn-id: svn://svn.code.sf.net/p/tigervnc/code/trunk@3607 3789f03b-4d11-0410-bbf8-ca57d06f2519

git-svn-id: svn://svn.code.sf.net/p/tigervnc/code/trunk@589 3789f03b-4d11-0410-bbf8-ca57d06f2519

git-svn-id: svn://svn.code.sf.net/p/tigervnc/code/branches/merge-with-vnc-4.1.1@522 3789f03b-4d11-0410-bbf8-ca57d06f2519

git-svn-id: svn://svn.code.sf.net/p/tigervnc/code/trunk@2 3789f03b-4d11-0410-bbf8-ca57d06f2519