Inspired by https://gitlab.gnome.org/GNOME/glib/-/issues/2638.
This requires moving the tests to subprocesses, so that
`g_log_set_writer_func()` is only called once per process.
It also adds a test for the new error.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
The pipe must be closed, or the child PID watch doesn't get triggered.
We should remove the message callback source on EOF, as EOF during main
loop run will reach a bad assert in the callback.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
...for certain Windows locales, since the formats accepted for
g_date_set_parse() will vary depending on the current system locale. For
instance, g_date_set_parse(gdate, "dd/mm/yy") is accepted on locales such
as zh-HK (Chinese (Hong Kong SAR)) but is rejected on zh-TW (Chinese
(Taiwan)).
One can tell from the "date format" settings in the Windows system
control panel whether there is a "dd/MM/YYYY" or "dd/MM/YY" option from the
drop-down list of date formats to display for the locale, which will indicate
whether g_date_set_parse(gdate, "dd/mm/yy") is accepted, which is true for
zh-HK but is not true for zh-TW.
If g_date_set_parse(gdate, "dd/mm/yy") is not accepted, try again with
g_date_set_parse(gdate, "yy/mm/dd") thereafter for the 2-digit-year tests.
This ensures that the output is redirected properly, and prefixed with
`#` when outputting in TAP mode, so that it doesn’t confuse the TAP
format parser.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
It currently fails on FreeBSD with:
```
Bail out! GLib:ERROR:../glib/tests/spawn-test.c:111:test_spawn_basics: assertion failed (erroutput == "sort: cannot read: non-existing-file.txt: No such file or directory\n"): ("sort: No such file or directory\n" == "sort: cannot read: non-existing-file.txt: No such file or directory\n")
```
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
The tests have to be conditional on C++11 being enabled, as the default
C++ standard on macOS is (for some reason), C++97 (`__cplusplus` is
defined as `199711L`).
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #2625
When running under msys2 (and supposedly cygwin), the root path is
remapped and permissions are permissive, the test doesn't fail.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
The handling of that case isn't well specified, and system dependent.
However if the system decided that "foo=bar" was the key, then don't
expect "foo" is set.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Both environment variables and GetThreadLocale() may interefere with the
glib case conversion logic.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
This should fix the Coverity build, which runs with
`-DGLIB_DISABLE_DEPRECATION_WARNINGS` defined in the environment (see
`.gitlab-ci.yml`).
See: https://gitlab.gnome.org/GNOME/glib/-/jobs/1907625
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
g_basename() function is defined in glib/gfileutils.c which is tested
by glib/tests/fileutils.c test set. Until now, g_basename() test was
in glib/test/utils.c. This patch move the unit test to the proper file.
This looks like a regression from commit 3356934db5, but prior to that
commit there was always an assertion failure when calling
`g_time_zone_new_offset()` with an offset which is too large (such as 44
hours), ever since the function was added in commit cf24867b93.
It would be ideal if we could return a `NULL` timezone to indicate the
error, but that’s not part of the API for `g_time_zone_new_offset()`, so
we have to go with the dated and not-ideal approach of returning the UTC
timezone and letting the caller figure it out.
Another potential approach would be to reduce the `offset` modulo 24
hours. This makes the error less easily detectable than if returning
UTC, though, and still returns an invalid result: `+44:00` is not the
same timezone as `+20:00` (it’s one day further ahead).
Add a unit test.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #2620
Otherwise the `start_thread()` threads and the main thread are competing
to iterate the global default context, which is probably not what was
intended.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
