This allows us to separate accidentally unused, from explicitly unused
parameters, which allows us to turn on such checks in the compiler.

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.

We do a lot of calculations based on pixel coordinates and we need
to make sure they do not overflow. Restrict the maximum dimensions
we support rather than try to switch over all calculations to use
64 bit integers.

This prevents attackers from from injecting code by specifying a
huge framebuffer size and relying on the values overflowing to
access invalid areas of the heap.

This primarily affects the client which gets both the screen
dimensions and the pixel contents from the remote side. But the
server might also be affected as a client can adjust the screen
dimensions, as can applications inside the session.

Issue found by Pavel Cheremushkin from Kaspersky Lab.

Don't allow subclasses to just override dimensions or buffer details
directly and instead force them to go via methods. This allows us
to do sanity checks on the new values and catch bugs and attacks.

It adds a lot of noise to the debug output with little gain.

This will allow us to use better formats that preserve the entire
alpha channel.

We need to restore the previous, more complex API in order to
easily handle masks now that we no longer accept out-of-bounds
operations.

There has been multiple attempts at tricking decoders to exceed
the boundaries of the active pixel buffer. Add extra checks to
prevent such invalid access.

It can be triggered by RRE message with subrectangle out of framebuffer
boundaries. It may prevent the same kind of issue caused by evil message
from another encoding too.

There has been some confusion if fillRect() should accept a buffer
or a pixel. This can cause misrendering if your data is not in the
native endian order. A buffer makes more sense here though, and
is what most of the callers are already assuming, so change the
API to follow that.

It had regressed in performance compared to 1.3. This brings it back
up to the same speed.

Allows you to modify the buffer with data in a
different pixel format.

Allows pixel buffers that do damage tracking to get
proper information.

Clearly separates the read API from the write API
and also from actual implementation.

It was confusing and not properly used everywhere.
Callers should use the stride they get when they get
the buffer pointer.

Keep things simple instead and allows us to remove the extra setPF()
methods.

Gets rid of a loooot of code and complexity.

Colour map clients are still supported through an
automatically generated map, but we lose the ability to
develop a client or server that uses colour maps
internally.

managed pixel buffer changes format. Also add a bit more
protection for switching pixel format as the base classes
aren't really designed for that. Fixes a crash with the
mouse pointer in WinVNC.
Based on work done by Daniel Wyatt (dewyatt).


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

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

just crashing.


git-svn-id: svn://svn.code.sf.net/p/tigervnc/code/trunk@4227 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