[cairo] const-ness fixes for transform_distance and transform_point

[Owen Taylor]

On Mon, 2005-05-09 at 10:07 -0700, Keith Packard wrote:
> On Mon, 2005-05-09 at 13:06 -0400, Owen Taylor wrote:
> 
> > This does muddle the "plain structure returns are out-parameters"
> > rule that I documented in the language binding appendix.
> 
> And what about the re-entrancy issues of returning a pointer to static
> data?  

 cairo_surface_t *cairo_get_target (cairo_t *cr);

is returning a pointer to non-referenced data, so that already prevents
us from enabling simultaneous access to the same cairo_t from 
multiple threads.

Returning a pointer to *global* static data is clearly evil.

(Not to argue against myself, just to clarify the situation)

> The C library suffers greatly from this in a number of APIs.
> Passing in a pointer to thread-specific data makes this all much
> clearer.
> 
> > void
> > cairo_get_matrix (cairo_t *cr, cairo_matrix_t *matrix);
> 
> I have a strange though here -- we could mark the cairo calls which do
> not change the state of the library by annotating the cairo_t* with
> 'const'.  Would this be a good idea?  Or would it only clutter the
> headers?  I'm not certain myself, but wanted to increase list traffic
> with side discussions.

IMO, just clutter. You start getting into corner cases pretty 
quickly. (Does cairo_reference() change its argument or not?
Does cairo_set_source() change its argument or not?)

The GTK+ is that we never use const on refcounted structures.

It's more an empirical rule than a theoretical one, but it
seems to work out OK in practice.

Regards,
						Owen

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.freedesktop.org/archives/cairo/attachments/20050509/3981b869/attachment.pgp