On 08/21/2017 09:48 PM, Michael Stahl wrote:
On 20.08.2017 17:59, Ulrich Gemkow wrote:
when building current master in Ubuntu 16.04 in a console
where LANG is set to US.iso88591 the unit test
ScFiltersTest::testUnicodeFileNameGnumeric()
in sc/qa/unit/subsequent_filters-test.cxx fails with the
following assertion:
===
assertion failed
- Expression: xDocSh.is()
ScFiltersTest::testUnicodeFileNameGnumeric finished in: 10ms
subsequent_filters-test.cxx:3937:Assertion
Test name: ScFiltersTest::testUnicodeFileNameGnumeric
assertion failed
- Expression: xDocSh.is()
===
The test passes when setting LANG to en_US.utf8.
I cannot judge whether this is acceptable behavior - today
it is IMHO not very common to set LANG to something other
than utf8.
quite frankly, if you set your build to a non-Unicode locale, it's a
case of "doctor, it hurts when i do this - well don't do that then".
it's bad enough that we had to deal with this nonsense on Windows, where
there OS doesn't allow setting a Unicode locale, but since MSVC 2015
added the "-utf-8" command line flag even that problem has gone away.
I think you're mixing two different issues here:
For one, there's the question of how non-ASCII C/C++ source code is
handled during the build. Please see
<https://lists.freedesktop.org/archives/libreoffice/2017-August/078299.html>
"Re: [Libreoffice-commits] core.git: tell msvc our source code is
written using utf-8".
For another, there's LO's way of determining a "system encoding" at
(test) runtime. (Which is where the issue was in this specific case,
cf.
<https://cgit.freedesktop.org/libreoffice/core/commit/?id=9a19e96d0d9df032d51748c02adb4fe778291afd>
"ScFiltersTest::testUnicodeFileNameGnumeric only works with UTF-8").
(And I have no idea whether there's legitimate reasons out there to
specify a non-UTF-8 Linux locale, or whether that could indeed be
considered a poor joke.)
_______________________________________________
LibreOffice mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/libreoffice
