GNOME Bugzilla – Bug 702136
test-suite fails with non-UTF8 locale
Last modified: 2013-06-18 07:39:13 UTC
In Debian our buildds use the default C locale. Using that, the test suite fails for the following two tests: terminate called after throwing an instance of 'Glib::ConvertError' ./dom_parse_entities/make-check-sh: line 2: 27043 Aborted "/tmp/libxml++2.6-2.36.0/examples/dom_parse_entities/dom_parse_entities" > /dev/null FAIL: dom_parse_entities/make-check-sh terminate called after throwing an instance of 'Glib::ConvertError' ./dom_parser/make-check-sh: line 2: 27062 Aborted "/tmp/libxml++2.6-2.36.0/examples/dom_parser/dom_parser" > /dev/null FAIL: dom_parser/make-check-sh To reproduce the problem, run LC_ALL=C make check
Looking at the example.xml files, only examples/dom_parser/example.xml and examples/dom_parse_entities/example.xml actually contain UTF-8 characters, which probably explains why only those two tests fail. I guess, we could either use std:wcout when outputting any of the text from the file or explicitly set a UTF-8 locale, like std::locale::global(std::locale("C.UTF-8"));
I guess we should just set the locale.
Created attachment 246727 [details] [review] patch: Examples dom_parse_entities and dom_parser: Better locale selection. Isn't it reasonable to use the user-specified locale, if possible? This patch does just that, and if it's not possible, it uses the C.UTF-8 locale. If that also fails, bad luck! Any comments? I've only changed the two failing test cases. A more consistent change would be to break out the locale-selecting code into a function in a separate file, and call that function at the start of all the test cases. I may do that, if we decide not to just select C.UTF-8 unconditionally. Can we be reasonably sure that it's possible to select C.UTF-8 in all systems, where libxml++ is used?
Actually, I think tests should run in a certain environment, so we should specify the locale. Then the tests results are reproducable. If we want to test other locales, we should do that explicitly and on purpose. I do that in Glom, for instance, though it demands that those locales are installed on the system.
The test cases in libxml++ are stored in the examples/ directory, not in tests/. That's because they were first made as examples, meant to be used manually by people who wanted to experiment with libxml++, xml files and dtd files. Then I changed them a bit, but obviously not enough, so 'make check' would do at least something. When these examples are used by 'make check' you don't want a lot of output (preferably no output at all) from tests that pass. I achieved that in a simple way, by sending std::cout to /dev/null. The Glib::ConvertErrors come from statements of type std::cout << str << std::endl; where str is a Glib::ustring. The right thing to do would be to add a --quiet option on all the examples, add that option to the make-check-sh shell scripts that 'make check' generates, and execute std::cout << ... statements only when --quiet is not specified. Then I think all tests would pass with any locale. Unfortunately there are about 150 such statements in total in the examples.
Created attachment 246845 [details] [review] patch: Examples dom_parse_entities and dom_parser: Fix when LC_ALL=C. Here's a wild idea. Glib::ustring is subclassed, and the subclass catches Glib::ConvertError in operator<<(). That way, the test can succeed even if such exceptions are thrown. These exceptions don't indicate an error in libxml++. Catching and ignoring them does not do any harm. I admit that it's quite an ugly hack, but it's reasonably easy to implement.
I have pushed a patch similar to the one in comment 6. https://git.gnome.org/browse/libxml++/commit/?id=1c56ed110075f4f8529fb67a9a235a751645a05f