Bug 84908 - Compilation errors with MSVC after recent changes to 'cairo-path-stroke-traps.c'
Summary: Compilation errors with MSVC after recent changes to 'cairo-path-stroke-traps.c'
Status: RESOLVED FIXED
Alias: None
Product: cairo
Classification: Unclassified
Component: general (show other bugs)
Version: unspecified
Hardware: Other Windows (All)
: medium normal
Assignee: Chris Wilson
QA Contact: cairo-bugs mailing list
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-10-11 10:40 UTC by John Emmas
Modified: 2014-12-04 09:25 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments
Another variant to solve the msvc compilation problem (1.56 KB, patch)
2014-10-16 19:15 UTC, Hans Breuer
Details | Splinter Review
A third proposal for solving the MSVC compilation issue (1.35 KB, patch)
2014-11-13 09:37 UTC, John Emmas
Details | Splinter Review

Description John Emmas 2014-10-11 10:40:44 UTC
Firstly, apologies. I'm not sure whether this needs to get filed under 'general' or under 'win32-backend' but anyway, here it is...

Since updating from git master about a week ago (ver 1.13.1) I can no longer compile 'cairo-path-stroke-traps.c' with Microsoft VC8. I get errors at lines 302, 303, 464 and 465. As an example, line 302 looks like this:-

cairo_point_t t[] = { in->point, *inpt, *outpt }

Given that 'in->point', '*inpt' and '*outpt' are all structs, I suspect the problem is that the compiler would need to generate a default copy c'tor for 'cairo_point_t'. MSVC does this when compiling as C++ but not when compiling as 'C'. Unfortunately, if I change my project to build as C++ I just get a whole slew of other errors elsewhere. So currently, I can't compile as 'C', nor as C++.

The errors at lines 302 and 303 can be fixed as follows. I'm not claiming that my fix is the most elegant one (and of course, somebody will need to verify that it fulfils the original intention) but it does at least compile!! If somebody wants to come up with a more elegant solution, this should at least tell them what's going wrong:-

1) Remove lines 302 and 303 and replace with the following code:-

cairo_point_t t[3];
cairo_point_t e[4];

memcpy( &t[0], &in->point, sizeof(cairo_point_t) );
memcpy( &t[1], inpt, sizeof(cairo_point_t) );
memcpy( &t[2], outpt, sizeof(cairo_point_t) );

memcpy( &e[0], &in->cw, sizeof(cairo_point_t) );
memcpy( &e[1], &in->ccw, sizeof(cairo_point_t) );
memcpy( &e[2], &out->cw, sizeof(cairo_point_t) );
memcpy( &e[3], &out->ccw, sizeof(cairo_point_t) );

2) It looks like the same fix would probably work for lines 464 and 465.

Hope that helps,

John
Comment 1 Hans Breuer 2014-10-16 19:15:27 UTC
Created attachment 107945 [details] [review]
Another variant to solve the msvc compilation problem

Also working and more similar to what was there before.
Comment 2 John Emmas 2014-10-17 10:59:40 UTC
Just want to confirm that Hans's variant does build okay with MSVC and it does produce correctly initialised arrays.

One question...  will this strategy work okay for other platform / compiler architectures (e.g. big-endian)? I suspect the answer's probably "yes" but I just wanted to raise that question.

Thanks Hans, for the prompt work!
Comment 3 John Emmas 2014-10-24 09:18:38 UTC
Following up...

Can we incorporate Hans's fix into the official code soon? I just updated a few minutes ago (from git master) but I'm still seeing the original code which doesn't compile :-(
Comment 4 John Emmas 2014-11-13 09:37:57 UTC
Created attachment 109394 [details] [review]
A third proposal for solving the MSVC compilation issue

For completeness, here's a 3rd solution for this problem (originally proposed on the mailing list by Thomas Berg). I've applied this patch locally and I can confirm that this one also compiles and links successfully.

Surely one of these proposals must now be acceptable??
Comment 5 Fan, Chun-wei 2014-11-13 09:42:03 UTC
Comment on attachment 107945 [details] [review]
Another variant to solve the msvc compilation problem

Hi,

I can confirm too that this patch works for me (Visual Studio 2008+, which also gets this problem).  The issue here is that Visual Studio 2005+ is quite strict on type conversions (so it wants code to be clear enough on conversions), and I think it makes sense from a correctness and a security point of view.  Although the code might not look that nice, but I think as Hans mentioned, it is consistent with the rest of Cairo.

Please consider this patch, especially as Cairo does need some update and work on the Windows side, and making it buildable with Visual Studio would be really helpful for that work.

Thanks very much for your time, with blessings!
Comment 6 John Emmas 2014-11-17 13:30:46 UTC
If Chris can't find time to deal with this, would it speed things up to re-assign it to someone else?
Comment 7 Bryce Harrington 2014-11-20 20:31:58 UTC
Hans' patch committed to trunk.

To ssh://git.cairographics.org/git/cairo
   2c5af59..56da7ad  master -> master

This looks eligible to backport to 1.14 as well, if it's needed there.
Comment 8 John Emmas 2014-12-01 18:16:10 UTC
(In reply to Bryce Harrington from comment #7)
> Hans' patch committed to trunk.
> 
> To ssh://git.cairographics.org/git/cairo
>    2c5af59..56da7ad  master -> master
> 
> This looks eligible to backport to 1.14 as well, if it's needed there.

Hi Bryce,

Sorry for the delay in replying. Master is now building fine again - but yes, the patch needs to get applied to 1.14 as well.

Any chance that this could get done in the next day or two? Thanks,

John
Comment 9 Uli Schlachter 2014-12-03 15:41:07 UTC
Cherry-picked to the 1.14 branch:

To ssh://git.freedesktop.org/git/cairo
   f6fd372..b2333fd  1.14 -> 1.14
Comment 10 John Emmas 2014-12-04 09:25:46 UTC
Just confirming that 1.14 is now buildable with MSVC again. Thanks.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.