libc++ breaks css parsing [upstream]

[Gellule]

Library libc++ is now the default C++ Standard Library on OSX 10.9 Mavericks. The following happens when building inkscape against libc++ (http://libcxx.llvm.org) instead of libstdc++:

If an object has fill:none, setting stroke changes fill to unset, but it appears as fill:one in the XML.
If an object has stroke:none, setting fill changes stroke to unset, but it appears as stroke:none in the XML.

How to reproduce:
1. Open a blank canvas.
2. Create a square.
3. Open the "Fill and Stroke" and "XML Editor" tabs.
4. Set the fill to "No Paint" (XML shows fill:none)
5. Set the stroke to "Flat color"

The square fill changes to black, unset is selected, and the XML shows fill:one.

[su_v (suv-lp)]

Not reproduced with r13242 on OS X 10.7.5 (default new prefs, default new document).

Could you attach your preferences file, or add more information about the original style of the square created in step 2?

(Note: with new preferences (old one renamed before launching inkscape), there is a (somehwat unexpected) behavior when changing the fill or the stroke of the first newly drawn shape (e.g. a rect with blue fill and 1px black stroke): the next shape drawn with a tool which uses 'Last used style' will only have the attribute set which was changed before, whereas the other one now is unset - this happens with older stable versions of Inkscape too).

[Gellule (gellule-xg)]

The initial square has the following style: "stroke:#000000;stroke-opacity:1", fill is undefined and appears black on screen.
I've moved my old preferences.xml away, and the behaviour stays. The style is however not a black rectangle with a blue fill, contrary to what the preferences file seems to indicate.

I may just have a packaging issue. But the problem is already there with the unmodified binary from macports' inkscape-devel.

[Gellule (gellule-xg)]

I've looked into my issue. It looks like I can fix it with the attached patch. Could this be related to clang and or C++11?

[jazzynico (jazzynico)]

Not reproduced on Windows XP, Inkscape trunk revision 13273.

[Gellule (gellule-xg)]

Looking into this further, it seems to be related to the use of libc++ instead of libstdc++, hence mostly OSX related.

The extraction operator (ss >> number, see patch above) in libc++ fails but still consumes a few characters, whereas in libstdc++ it fails also but does not consume them. This seems somewhat related to http://llvm.org/bugs/show_bug.cgi?id=15154.

Could someone with OSX Mavericks and macports check that there is indeed an issue as described in the bug report? Simplest would be to use the inkscape-devel port.

[Gellule (gellule-xg)]

Confirmed as upstream issue of libc++:
http://llvm.org/bugs/show_bug.cgi?id=19354
http://llvm.org/bugs/show_bug.cgi?id=17782

The previously attached patch is a workaround.

[su_v (suv-lp)]

On 2014-04-07 16:01 +0100, Gellule wrote:
> Could someone with OSX Mavericks and macports check that there is indeed
> an issue as described in the bug report? Simplest would be to use the
> inkscape-devel port.

AFAIK only Johan Engelen has access to Mavericks right now, and occasionally does build inkscape trunk there (with default MacPorts variants i.e. GTK+/X11). I'll try to contact him whether he'd be able to confirm the report, and review the proposed patch.

In the meantime, I'll keep the patch applied to local builds on OS X 10.7.5 (using libstdc++, compiled with llvm-gcc-4.2 and clang (LLVM 3.1svn)). So far it does not seem to have unintended side effects (at least wrt the steps to reproduce this report). Or do you think it would need to be #ifdef'ed depending on C++11, or __apple_build_version__?

[su_v (suv-lp)]

BTW - I can reproduce the libc++ bug on 10.7.5 using the example code in your llvm bug report:

Chillida:work su_v$ clang++ -stdlib=libstdc++ -o llvm_bug llvm_bug.cpp
Chillida:work su_v$ ./llvm_bug
Failed!
Position: 0
Chillida:work su_v$ clang++ -stdlib=libc++ -o llvm_bug llvm_bug.cpp
Chillida:work su_v$ ./llvm_bug
Failed!
Position: 3
Chillida:work su_v$

[su_v (suv-lp)]

AFAICT the code in question was added in rev 10629:
<http://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/revision/10629#src/xml/repr-css.cpp>

Can you confirm that this does not affect the stable branch <lp:inkscape/0.48.x>?

[Gellule (gellule-xg)]

Thanks for confirming!

The attached patch should not need to be #ifdef'ed. With libstdc++ "ss.seekg(0);" is a no-op, since the ss position is already at 0. I would maybe add a comment next to "ss.seekg(0);", explaining why it was added.

I've tried macports' inkscape port, based on 0.48.4: the issue does not show. No back port needed, it seems.

[su_v (suv-lp)]

@Gellule - any chance you could have a look at bug #1306865? I suspect it is the same underlying issue, but can't verify since I don't have access to a Mac with Mavericks installed …

[Papoj Thamjaroenporn (papojt)]

@~suv, thank you for pointing me to this post. The patch proposed by @Gellule actually solves my problem. Thank you!

[Johan Engelen (johanengelen)]

I applied your patch in rev 13285, thanks for the patch Gellule! (I added a comment about why the extra line of code is there)