_cairo_malloc(0) always returns NULL, but has not been used
consistently. This patch replaces many calls to malloc() with
_cairo_malloc().
Fixes: fdo# 101547
CVE: CVE-2017-9814 Heap buffer overflow at cairo-truetype-subset.c:1299
Reviewed-by: Bryce Harrington <bryce@osg.samsung.com>
This quells the following warnings:
src/cairo-xml-surface.c:576:5: warning: passing argument 2 of
‘_cairo_xml_surface_emit_clip_boxes’ discards ‘const’ qualifier from
pointer target type
src/cairo-xml-surface.c:462:1: note: expected ‘struct cairo_clip_t
*’ but argument is of type ‘const struct cairo_clip_t *’
Most of the cairo_xml*emit* routines const their source objects;
these should follow suit.
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Edward Zimmerman pointed out that the xml surface had bitrotted slightly
and no longer understand the new clip layout - in particular that we can
have clips without a path, but just with boxes instead.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
The xml backend structure was being initialized with the wrong
functions, resulting in multiple "initialization from incompatible
pointer type" warnings.
The existing API only described the method to be used for performing
rasterisation and unlike other API provided no opportunity for the user
to give a hint as to how to trade off performance against speed. So in
order to no be overly prescriptive, we extend the NONE/GRAY/SUBPIXEL
methods with FAST/GOOD/BEST hints and leave the backend to decide how
best to achieve those goals.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
A common requirement is the fast upload of pixel data. In order to
allocate the most appropriate image buffer, we need knowledge of the
destination. The most obvious example is that we could use a
shared-memory region for the image to avoid the transfer cost of
uploading the pixels to the X server. Similarly, gl, win32, quartz...
The other side of the equation is that for manual modification of a
remote surface, it would be more efficient if we can create a similar
image to reduce the transfer costs. This strategy is already followed
for the destination fallbacks and this merely exposes the same
capability for the application fallbacks.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Step 1, fix the failings sighted recently by tracking clip-boxes as an
explicit property of the clipping and of composition.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Allow a backend to completely reimplement the Cairo API as it wants. The
goal is to pass operations to the native backends such as Quartz,
Direct2D, Qt, Skia, OpenVG with no overhead. And to permit complete
logging contexts, and whatever else the imagination holds. Perhaps to
experiment with double-paths?
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Using double precision for gradient extreme objects ensures that they
are preserved as specified when constructing the gradient pattern.
Fixes huge-linear, huge-radial.
Fixes part of https://bugs.freedesktop.org/show_bug.cgi?id=32215
Path are always interpreted in forward direction, so the ability of
interpreting in the opposite direction (which is very unlikely to be
useful at all) can be removed.
I updated the Free Software Foundation address using the following script.
for i in $(git grep Temple | cut -d: -f1 )
do
sed -e 's/59 Temple Place[, -]* Suite 330, Boston, MA *02111-1307[, ]* USA/51 Franklin Street, Suite 500, Boston, MA 02110-1335, USA/' -i "$i"
done
Fixes http://bugs.freedesktop.org/show_bug.cgi?id=21356
We were exposing the actual value of CAIRO_FORMAT_INVALID
through API functions already, so it makes sense to just
go ahead and put it in the cairo_format_t enum.
The device is a generic method for accessing the underlying interface
with the native graphics subsystem, typically the X connection or
perhaps the GL context. By exposing a cairo_device_t on a surface and
its various methods we enable finer control over interoperability with
external interactions of the device by applications. The use case in
mind is, for example, a multi-threaded gstreamer which needs to serialise
its own direct access to the device along with Cairo's across many
threads.
Secondly, the cairo_device_t is a unifying API for the mismash of
backend specific methods for controlling creation of surfaces with
explicit devices and a convenient hook for debugging and introspection.
The principal components of the API are the memory management of:
cairo_device_reference(),
cairo_device_finish() and
cairo_device_destroy();
along with a pair of routines for serialising interaction:
cairo_device_acquire() and
cairo_device_release()
and a method to flush any outstanding accesses:
cairo_device_flush().
The device for a particular surface may be retrieved using:
cairo_surface_get_device().
The device returned is owned by the surface.
As a simple step to ensure that we do not inadvertently modify (or at least
generate compiler warns if we try) user data, mark the incoming style
and matrices as constant.
Replaying a meta surface can be achieved by using it as a source for a
cairo_paint() so exporting a separate API is unnecesary and confusing.
So after consulting Chris and Carl, we decided to remove the function
again.
A very simple surface that produces a hierarchical DAG in a simple XML
format. It is intended to be used whilst debugging, for example with the
automatic regression finding tools of cairo-sphinx, and with test suites
that just want to verify that their code made a particular Cairo call.
