[cairo] Potential bug on multiple functions in cairo-clip.c
Jindong (JD) Chen
jdchen at gmail.com
Thu Jun 11 10:36:51 PDT 2009
I patched up my local copy with the fix and it worked for me. Thanks a lot.
On Thu, Jun 11, 2009 at 10:08 AM, Chris Wilson<chris at chris-wilson.co.uk> wrote:
> On Thu, 2009-06-11 at 09:56 -0700, Jindong (JD) Chen wrote:
>> It seems to be a bug to me that, in cairo-1.8.6, a list of functions
>> in cairo-clip.c return
>> although their return type is cairo_status_t.
>> CAIRO_INT_STATUS_UNSUPPORTED, which is 100, does not work well with macro
>> #define _cairo_status_is_error(status) \
>> (status != CAIRO_STATUS_SUCCESS && status <= CAIRO_STATUS_LAST_STATUS)
> Indeed we assert that internal status values cannot be propagated back
> to the user. The fact that our internal interfaces return cairo_status_t
> where they mean cairo_int_status_t has been annoying me for a long time.
> It would be nice to spend the time to clean it up so that stronger type
> checkers (sparse, C++) do not warn about our mixing of enums, but since
> it's highly unlucky to actually uncover a bug I've not been motivated to
> spend the time to do so.
>> In my case,
>> is returned from the call to _cairo_gstate_clip() in function
>> cairo_clip_preserve(), and cause _cairo_set_error() to choke on it.
> This is a bug due to an uninitialized variable, fixed in:
> commit a5c1cdf2b030959309e1645bd115f058f1367296
> Author: M Joonas Pihlaja <jpihlaja at cc.helsinki.fi>
> Date: Thu Nov 13 12:11:12 2008 +0200
> [clip] Fix uninitialised status return in
> This fixes the clip-all test case crashing for me.
> and will be included in the forthcoming 1.8.8 release.
> Have fun using Cairo!
More information about the cairo