test string:string_upper is locale dependent

[matko]

While building SWI-Prolog from source, I discovered ctest would fail in certain environments and not in others. It turns out that there's a single test, string:string_upper, which succeeds or fails depending on the contents of the LANG environment variable. This test mentions #1262 as a related issue, so I am linking it here.

Since the relevant test is just plain prolog we can actually easily reproduce outside of the build.
In a swipl source tree, run

env LANG=C swipl -f src/Tests/core/test_string.pl -g run_tests

Which on my machine gives me

❯ env LANG=C swipl -f src/Tests/core/test_string.pl -g run_tests -t halt
[15/27] string:string_upper ...................................................................................... **FAILED (0.000 sec)
ERROR: /home/maren/src/swipl-devel/src/Tests/core/test_string.pl:88:
ERROR:     test string:string_upper: 
ERROR: wrong answer for L (compared using ==)
ERROR:     Expected: "WH\u0178"
ERROR:     Got:      "WH\u00FF"
[27/27] string_bytes:hello ......................................................................................... passed (0.000 sec)
ERROR: 1 test failed
% 26 tests passed
% Test run completed in 0.017 seconds (0.017 cpu)
ERROR: -g run_tests: false

Since the tests are run through ctest, similarly

env LANG=C ctest

from the build directory will trigger this.

[kamahen]

This is a known problem (I think I once filed a similar bug, although I can't find it) and many of the functions take an "encoding" parameter to deal with this. There's not a lot that can be done if the cause is the underlying C functions and locale.

Possibly related: #1013

[matko]

It is reasonable that certain predicates behave differently depending on the set locale. But the build should not pass or fail based on the locales in the build environment. So any automated tests that run as part of that build should be able to deal with locales being different.

I think we could probably just hardcode the locale used during the build or something.

[JanWielemaker]

Note that other tests require a UTF-8 based locale. I think they are silently disabled if this is not the case. I am not aware of a portable way to get a suitable locale. On (most?) Linux systems, C.utf8 is the best choice. I'm also not aware of a way to specify the locale for running the tests in CMake. In this case, we probably need to make sure the test passes under all locales. I think this checks that some character codes < 256 may return a converted character >= 256. But indeed, only under some locales ...

[JanWielemaker]

Pushed a patch that makes the test pass regardless of the locale. It turns out that one can specify the environment for a test using the ENVIRONMENT property on a test. The next challenge is a way to get the name of a Unicode-aware locale that works on all systems?

[matko]

The test run for the master branch now runs without failures for me in all environments. That means I can now turn on those tests by default as part of the package build. Yay :)

The next challenge is a way to get the name of a Unicode-aware locale that works on all systems?

Nothing is better than C.utf8, probably?

[JanWielemaker]

Nothing is better than C.utf8, probably?

Does not exist on MacOS 😢 The GNU docs say only C and POSIX are required to exist. Most systems do seem to follow the naming conventions of locale, which optionally end in .<charset>. So, possibly we can run locale -a and see whether we have C.utf8 or en*.utf8 or just any *.utf8? Probably after validating that the current locale is not an UTF-8 based locale?