[cairo-commit] 2 commits - perf/README README src/cairo-pattern.c test/README

[Carl Worth]

 README              |    4 ++--
 perf/README         |    6 +++---
 src/cairo-pattern.c |    2 ++
 test/README         |    6 +++---
 4 files changed, 10 insertions(+), 8 deletions(-)

New commits:
diff-tree 13cae8b5e6d3fc93c4eb1853b91ba356b572b551 (from 027915717df6e203826d10da7bfdf8e26af13ee1)
Author: Carl Worth <cworth at cworth.org>
Date:   Mon Aug 6 11:06:47 2007 -0700

    Ensure that a copied pattern gets its own user_data array
    
    This fixes the bug reported here:
    
    	Segfault with cairo_pattern_set_user_data
    	https://bugs.freedesktop.org/show_bug.cgi?id=11855

diff --git a/src/cairo-pattern.c b/src/cairo-pattern.c
index 24efa34..2fd1c87 100644
--- a/src/cairo-pattern.c
+++ b/src/cairo-pattern.c
@@ -185,7 +185,9 @@ _cairo_pattern_init_copy (cairo_pattern_
     } break;
     }
 
+    /* The reference count and user_data array are unique to the copy. */
     pattern->ref_count = 1;
+    _cairo_user_data_array_init (&pattern->user_data);
 
     return CAIRO_STATUS_SUCCESS;
 }
diff-tree 027915717df6e203826d10da7bfdf8e26af13ee1 (from 72c1f5d802c32f97ae5c0cbf899dc3a12fc28222)
Author: Nis Martensen <nis.martensen at web.de>
Date:   Wed Jul 4 07:09:00 2007 -0700

    Typo fixes in README files

diff --git a/README b/README
index 351fce0..bbf0663 100644
--- a/README
+++ b/README
@@ -14,7 +14,7 @@ while taking advantage of display hardwa
 (for example, through the X Render Extension).
 
 The cairo API provides operations similar to the drawing operators of
-PostScript and PDF. Operations in cairo including stroking and filling
+PostScript and PDF. Operations in cairo include stroking and filling
 cubic Bézier splines, transforming and compositing translucent images,
 and antialiased text rendering. All drawing operations can be
 transformed by any affine transformation (scale, rotation, shear,
@@ -134,7 +134,7 @@ Font backends:
 	    (excluding Windows Me.) Most testing has been done on
 	    Windows XP. While some portions of the code have been
 	    adapted to work on older versions of Windows, considerable
-	    work still needs to done to get cairo running in these
+	    work still needs to be done to get cairo running in these
 	    environments.
 
 	    Cairo can be compiled on Windows either with the GCC
diff --git a/perf/README b/perf/README
index b713dd0..d41142a 100644
--- a/perf/README
+++ b/perf/README
@@ -4,7 +4,7 @@ One of the simplest ways to run the perf
 
     make perf
 
-while will give a report of the speed of each indivudual test. See
+which will give a report of the speed of each individual test. See
 more details on other options for running the suite below.
 
 Running the cairo performance suite
@@ -25,7 +25,7 @@ examples of running it:
     ./cairo-perf -r -i 10 paint >> cairo.perf
 
 Raw results aren't useful for reading directly, but are quite useful
-when using cairo-perf-diff to compare spearate runs (see more
+when using cairo-perf-diff to compare separate runs (see more
 below). The advantage of using the raw mode is that test runs can be
 generated incrementally and appended to existing reports.
 
@@ -71,7 +71,7 @@ example:
     ./cairo-perf-diff aa883123d2af90
 
 Also, when passing git revisions to cairo-perf-diff like this, it will
-automatically cache results and re-use them rather than re-rerunning
+automatically cache results and re-use them rather than re-running
 cairo-perf over and over on the same versions. This means that if you
 ask for a report that you've generated in the past, cairo-perf-diff
 should return it immediately.
diff --git a/test/README b/test/README
index 468ff4a..90f0287 100644
--- a/test/README
+++ b/test/README
@@ -7,7 +7,7 @@ Using this test should be as simple as r
 assuming that the cairo distribution in the directory above has been
 configured and built. The test suite here goes through some effort to
 run against the locally compiled library rather than any installed
-version, but those efforts may fall short depending the level of your
+version, but those efforts may fall short depending on the level of your
 libtool madness.
 
 The test suite needs to be run before any code is committed and before
@@ -23,7 +23,7 @@ to circumvent the "pass" requirements li
 
 To limit the backends that the tests are run against, use the
 TARGETS make variable, that can also be passed to make.
-It should contain a (space-, comma-, etc-separate) list of backends to test.
+It should contain a (space-, comma-, etc-separated) list of backends to test.
 To limit the tests run, use the TESTS make variable, which should be a
 space-separated list of tests to run.  For example:
 
@@ -56,7 +56,7 @@ the style of existing tests. The new-bug
 the desired result of new-bug.c if the bug were fixed.
 
 Makefile.am should be edited, adding new-bug.c to both the TESTS and
-XFAIL_TESTS lists and new-bug-ref.png to EXTRA_DIST, add new-bug to
+XFAIL_TESTS lists and new-bug-ref.png to EXTRA_DIST. Add new-bug to
 .gitignore, and last but not least, don't forget to "git add" the new
 files.