summaryrefslogtreecommitdiff
path: root/test/cairo-test-trace.c
Commit message (Collapse)AuthorAgeFilesLines
* Avoid misuse of ctype(3) functionsTaylor R Campbell2023-03-291-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The ctype(3) character classification and mapping functions have a peculiarly limited definition (C11, Sec. 7.4 `Character handling <ctype.h>', p. 200): `The header <ctype.h> declares several functions useful for classifying and mapping characters. In all cases the argument is an int, the value of which shall be representable as an unsigned char or shall equal the value of the macro EOF. If the argument has any other value, the behavior is undefined.' In other words, in the most common case of 8-bit char and EOF = -1, the domain of the 257 allowed arguments is: -1, 0, 1, 2, ..., 254, 255 The ctype(3) functions are designed for use with stdio functions like getchar and fgetc which return int values in the same domain. In an ABI where char is signed (e.g., x86 SysV ABI used by most Unixish operating systems), passing an argument of type char as is can go wrong in two ways: 1. The value of a non-EOF input octet interpreted as `char' may coincide, as an integer, with the value of EOF, leading to wrong answers for some non-EOF inputs. E.g., if EOF = 1, and an input octet has all bits set, i.e., 255 as an unsigned char, then as a char the value is -1, which will be confused with EOF. In the ISO-8859-1 locale, the code point 255 is (in Unicode terminology) LATIN SMALL LETTER Y WITH DIAERESIS, for which isprint, isalpha, &c., are true. But isprint, isalpha, &c., are false for EOF. So if char *s points to a string with that character, isprint(*s) will return false when it should return true. 2. Passing a negative char whose value does not coincide with EOF is undefined behaviour. This isn't purely theoretical: often the functions are implemented by an array lookup, #define isprint(c) (ctypetab[c] & ISPRINT). If c is out of range (e.g., 192, ISO-8859-1 for LATIN CAPITAL LETTER A WITH GRAVE, which convers to (signed) char as -64), then you can get garbage answers by reading uninitialized memory or application crashes with SIGSEGV if the page preceding the table is unmapped. If what you have is an arbitrary char (e.g., from a char * string pointing at user input), then the only correct way to use the ctype(3) functions is by converting to unsigned char first -- e.g., isprint((unsigned char)*s). (If the functions were defined as macros that convert to unsigned char first, they would then spuriously interpret EOF as a non-EOF, so they can't do that themselves.) It is possible, in some cases, to prove that the input always actually lies in {0, 1, 2, ..., 127}, so the conversion to unsigned char is not necessary. I didn't check whether this was the case -- it's safer to just adopt the habit of always casting char to unsigned char first before using the ctype(3) macros, which satisfies a compiler warning on some systems designed to detect this class of application errors at compile-time.
* Fix some warningsAdrian Johnson2021-08-221-2/+4
|
* Remove stray _GNU_SOURCE definitionsEmmanuele Bassi2021-05-011-2/+0
| | | | | | We define _GNU_SOURCE globally in both the Autotools build, through the use of the AC_USE_SYSTEM_EXTENSIONS macro; and in the Meson build, with add_project_arguments().
* Handle new Cairo formats in test-traceEmmanuele Bassi2021-04-271-0/+2
| | | | We are missing RGB96F and RGBA128F.
* build: Include correct poll.hGeorge Matsumura2020-09-051-1/+9
| | | | | | | | | Including sys/poll.h when poll.h is available produces a compile warning on some systems, but only sys/poll.h is present on others such as AIX. This makes sure the most suitable poll.h is included in each situation. Signed-off-by: George Matsumura <gmmatsumura01@bvsd.org>
* meson: Fix musl buildGeorge Matsumura2020-09-021-3/+4
| | | | | | | This constitutes few fixes that are necessary to compile correctly and reduce errors when using musl libc. Signed-off-by: George Matsumura <gmmatsumura01@bvsd.org>
* skip MAP_NORESERVE when unsupportedMichael Haubenwallner2015-03-051-0/+4
| | | | | | | Fixes a compilation on AIX ('MAP_NORESERVE' undeclared) Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=89340 Signed-off-by: Bryce Harrington <bryce@osg.samsung.com>
* boilerplate: Remove unused thread id parameterAndrea Canciani2011-11-121-1/+0
| | | | | The thread id is not used anymore (it is always == 0), so it can be removed.
* Improve the documentation of the flagsAndrea Canciani2011-11-121-4/+3
| | | | | Some utilities were providing incorrect or incomplete usage information.
* Sort option flagsAndrea Canciani2011-11-121-1/+1
| | | | | | | | Keep the option flags in alphabetical order. This makes it easier to check for collisions or missing handlers. Avoids an internal error when passing flags -c, -r or -v to cairo-analyse-trace.
* test/trace: Hack to dump out per-context images and tracesChris Wilson2011-09-211-3/+14
| | | | Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
* test: Hack cairo-test-trace to write at trace for all contextsChris Wilson2011-09-161-10/+29
| | | | Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
* Introduce a new compositor architectureChris Wilson2011-09-121-79/+116
| | | | | | | | | | | | | | | | | | Having spent the last dev cycle looking at how we could specialize the compositors for various backends, we once again look for the commonalities in order to reduce the duplication. In part this is motivated by the idea that spans is a good interface for both the existent GL backend and pixman, and so they deserve a dedicated compositor. xcb/xlib target an identical rendering system and so they should be using the same compositor, and it should be possible to run that same compositor locally against pixman to generate reference tests. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> P.S. This brings massive upheaval (read breakage) I've tried delaying in order to fix as many things as possible but now this one patch does far, far, far too much. Apologies in advance for breaking your favourite backend, but trust me in that the end result will be much better. :)
* Introduce the cairo-missing libraryAndrea Canciani2011-09-021-46/+1
| | | | | | | | | | | | | | The cairo-missing library provides the functions which are needed in order to correctly compile cairo (or its utilities) and which were not found during configuration. Fixes the build on MacOS X Lion, which failed because of collisons between the cairo internal getline and strndup and those in libc: cairo-analyse-trace.c:282: error: static declaration of ‘getline’ follows non-static declaration /usr/include/stdio.h:449: error: previous declaration of ‘getline’ was here cairo-analyse-trace.c:307: error: static declaration of ‘strndup’ follows non-static declaration ...
* Remove useless checks for NULL before freeingAndrea Canciani2011-07-311-4/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch has been generated by the following Coccinelle semantic patch: // Remove useless checks for NULL before freeing // // free (NULL) is a no-op, so there is no need to avoid it @@ expression E; @@ + free (E); + E = NULL; - if (unlikely (E != NULL)) { - free(E); ( - E = NULL; | - E = 0; ) ... - } @@ expression E; @@ + free (E); - if (unlikely (E != NULL)) { - free (E); - }
* build: Rework pthread detection.M Joonas Pihlaja2010-07-111-5/+5
| | | | | | | | | | Use two levels of pthread support: a minimal level used to build cairo itself, and a full level to build threaded apps which want to use cairo. The minimal level tries to use pthread stubs from libc if possible, but falls back to the full level if that's not possible. We use CFLAGS=-D_REENTRANT LIBS=-lpthread to find a real pthread library since that seems to work on every unix-like test box we can get our hands on.
* test-suite: add image_diff_is_failure() functionBenjamin Otte2010-04-281-2/+1
| | | | | This cleans the code and fixes a boolean logic error where this check was done manually.
* script: Port cairo_script_context_t to cairo_device_tChris Wilson2010-01-221-3/+4
| | | | Use the unifying cairo_device_t for cairo_script_context_t and replace.
* [meta] Rename cairo_meta_surface_t to cairo_recording_surface_t.M Joonas Pihlaja2009-10-221-24/+24
| | | | | | | The new name is more descriptive than the rather opaque meta surface. Discussed with vigour on the mailing list and #cairo: http://lists.cairographics.org/archives/cairo/2009-July/017571.html
* [build] Link against pthread-stubsChris Wilson2009-10-151-5/+5
| | | | | | Avoid pulling in the real pthread library if the application is single threaded and not using pthreads, by linking against pthread-stubs instead.
* [API] Make _cairo_meta_surface_replay() private againBenjamin Otte2009-09-301-2/+6
| | | | | | | 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.
* [script] Introduce cairo_script_context_tChris Wilson2009-08-291-1/+4
| | | | | | cairo_script_context_t is an encapsulation object for interfacing with the output - multiple surfaces can share the same context, meaning that they write to the same destination file/stream.
* [test] Rename some structures within cairo-test-traceChris Wilson2009-07-051-112/+112
| | | | | Simply rename a few structures so that their names are less confusing with the mix of process and threads used to executes traces.
* Export meta-surfaceChris Wilson2009-07-031-38/+20
| | | | | | | | | | The meta-surface is a vital tool to record a trace of drawing commands in-memory. As such it is used throughout cairo. The value of such a surface is immediately obvious and should be applicable for many applications. The first such case is by cairo-test-trace which wants to record the entire graph of drawing commands that affect a surface in the event of a failure.
* [test] Record trace to an in-memory meta-surfaceChris Wilson2009-07-031-42/+329
| | | | | | | | | Requires hooking into test-meta-surface currently. Export meta-surface! The idea is that on detection of an error, we can reconstruct a minimal trace from the meta-surface. The first step is to simply dump the trace for the failing meta-surface. Later, we should automatically minimise this further.
* [test] Fix the image compareChris Wilson2009-06-211-15/+86
| | | | Oh, it's a bad sign when I can't even correctly compare a bunch of pixels.
* [test] Experiment with reference targetsChris Wilson2009-06-191-39/+190
| | | | | | Specify another boilerplate target to use as the reference for this target. We then use this in cairo-test-trace in preference to using the image surface. Still not perfect, though the framework is improving.
* [test] Minor tweak to cairo-test-traceChris Wilson2009-06-131-7/+9
| | | | Cleanse the code of a couple of redundant pointer manipulations.
* [test] Need SOURCE when copying image dataChris Wilson2009-06-131-0/+1
| | | | | | | | As cairo-test-trace does not clear the image data before reuse, using the default OVER operator will cause differing results for each process when inadvertently alpha blending into the shared memory region. As we essentially want to just copy the source pixels, be explicit and set the SOURCE operator.
* [test] Remove dlmallocChris Wilson2009-06-131-51/+11
| | | | | | cairo-test-trace's shared memory allocation pattern is much simpler than anticipated as it allocates a bunch of images and then frees them all, and so only needs a simple linear allocator.
* [test] Code review after sleepChris Wilson2009-06-131-164/+236
| | | | | | Review cairo-test-trace.c and rewrite parts to ease understanding and fix various bugs - such as failure to notice the slaves crashing and not releasing our shared memory after an interrupt.
* [test] Add cairo-test-traceChris Wilson2009-06-121-0/+1225
The basic premise is that we feed the trace to multiple backends in parallel and compare the output at the end of each context (based on the premise that contexts demarcate expose events, or their logical equivalents) with that of the image[1] backend. Each backend is executed in a separate process, for robustness, with the image data residing in shared memory and synchronising over a socket. [1] Should be reference implementation, currently the image backend is considered to be the reference for all other backends.
View Lorry Controller Status