[cairo] libcairowrap (was [Bug 13303] _cairo_pen_find_active_cw_vertex_index failed assertion)

[Benjamin Otte]

> And thanks for the report from libcairowrap. That tool's output is
> definitely looking really good.
>
Thanks. It's currently "just" a neat printf wrapper around cairo
functions where I made the printfs emit something that looks close to
compilable C code, so it fits into a simple C file. I just randomly
hack on it whenever I feel it makes dragging a testcase out of a Flash
file easier.
If someone wanted to make it smarter, it would need to keep various
state and therefore require data structures, which would probably be
more than just a trivial amount of work, which is why I didn't do it
yet.

I for example would love if it grouped stuff into functions by cairo_t
or cairo_surface_t so that you could easier find where the object. But
that thing alone would require keeping info about all of cairo's valid
objects plus not dumping the code because of reordering.

>    1. The numbers need to be printed as valid C literals, (that is, a
> locale-independent printing of floating-point numbers). The current
> -45,6667 where C wants -45.6667 is not too useful. :-)
>
As far as I know, there is no function in libc that does this,
otherwise I'd have used it. I just know glib provides a special
version of it. And I didn't want to call setlocale, as that has too
many side effects. For now, just running the code with LC_ALL=C should
do the trick.

>    2. Instead of cr_0xdeadbeef it would be nice to just have the tool
> identify matching pointers and map them to small integers. So "cr",
> "cr2", "cr3" or so.
>
Yeah, that would be nice. Unfortunately, this requires mapping
pointers to strings, and that requires a hash table. So we're back at
what I said above.
It would also be nice if it wouldn't declare those variables inline
(C99ism) and if it wouldn't redeclare symbols when a pointer was
identical to a previous one. But you can search/replace those easily,
so it's not a really big deal.

> Maybe libcairowrap should periodically emit something to explicitly set
> relevant cairo state such as the CTM? That would let reporters quote
> output back to the last such snapshot and ensure that all state was
> captured.
>
I don't think that's a good idea, just because it alters the order of
cairo function calls. And that is something I wouldn't want this tool
to do. What it could do however is add checks - like cairo_get_matrix
(cr, &mat); assert (mat.xx = 25.1); - but I'm not sure this is useful
either. We just need to be sure that we capture all available cairo
functions properly, and that can be done by comparing libcairowrap's
list of symbols with those actually in cairo.

Besides, it doesn't fix the hard part: cutting out unnecessary parts
of the dump, which still needs to be done manually.

> Benjamin, I assume this is a recent version. We should probably go
> ahead and host a repository for this on git.freedesktop.org to be more
> "official". Any reason not to do that?
>
No reason at all. I just had no place to put it,because a) I can only
open new git repos in my home directory and b) I don't think I have
write access to the cairo repositories.

Cheers,
Benjamin