This is a combination of g_hash_table_lookup_extended() and
g_hash_table_steal(), so that users can combine the two to reduce code
and eliminate a pointless second hash table lookup by
g_hash_table_steal().
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=795302
It seems that the test expects g_date_time_format to return formatted
results in English, and there is no setlocale (LC_ALL, "") call in the
file so the test does run in the default C locale. However, gettext
seems to read the value of LC_MESSAGES from the environment by itself.
Even if the value of LC_MESSAGES locale is C because of not calling
setlocale, gettext still translates the name of the month according to
the LC_MESSAGES environment variable, causing g_date_time_format_locale
to fail on the "%b" test case because it cannot convert UTF-8 text
returned by get_month_name_with_day to ASCII.
To avoid the test failure, we set the LC_MESSAGES environment variable
to C before format tests and restore it at the end of the function.
https://bugzilla.gnome.org/show_bug.cgi?id=795165
All those logging functions already add a newline to any message they
print, so there’s no need to add a trailing newline in the message
passed to them.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Reviewed-by: nobody
Spotted when temporarily compiling with -Wwrite-strings. This only goes
a small way towards making the code base -Wwrite-strings–clean. It
introduces no functional changes, and fixes no bugs.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Reviewed-by: nobody
Fix various warnings regarding unused variables, duplicated
branches etc by adjusting the ifdeffery and some missing casts.
gnulib triggers -Wduplicated-branches in one of the copied files,
disable as that just makes updating the code harder.
The warning indicating missing features are made none fatal through
pragmas. They still show but don't abort the build.
https://bugzilla.gnome.org/show_bug.cgi?id=793729
This is a non-trivial accessor which gets the identifier string used to
create the GTimeZone — unless the string passed to g_time_zone_new() was
invalid, in which case the identifier will be `UTC`.
Implementing this required reworking how timezone information was loaded
so that the tz->name is always set at the same time as tz->t_info, so
they are in sync. Previously, the tz->name was unconditionally set to
whatever was passed to g_time_zone_new(), and then not updated if the
tz->t_info was eventually set to the default UTC information.
This includes tests for the new g_time_zone_get_identifier() API, and
for the g_date_time_get_timezone() API added in the previous commit.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=795165
gdatetime testcase uses glib (which uses libintl), but *alsi* calls
libintl functions on its own, as part of the testing process.
Therefore it must be linked to libintl like any other program that
uses it.
https://bugzilla.gnome.org/show_bug.cgi?id=794556
date.c uses SUBLANG_LITHUANIAN_LITHUANIA which is Vista+
Include config.h so that _WIN32_WINNT is defined and the newer macros
are exposed.
This fixes the build under MinGW.
https://bugzilla.gnome.org/show_bug.cgi?id=793729
This patch relaxes the comparison rules and allow the month names to be
in a mixed case.
Translators should be allowed to provide the month names in a different
case (lower/upper case, not grammatical case) from the content of glibc
because it is disputable at the moment whether the month names should
follow the language rules strictly and be titlecased only if it is
obligatory to titlecase them or they should be also titlecased in the
standalone case. Hopefully in future a conversion specifier will be
invented to control the upper/lower case individually.
https://bugzilla.gnome.org/show_bug.cgi?id=793645
See the previous commit. By convention, GLib assumes strings loaded from
gettext are always in UTF-8, but we do need to tell gettext this. In
most other tests, it doesn’t matter; but in the gdatetime test, we test
re-encoding month names from EUC-JP, so we need to ensure the
translations start in UTF-8 correctly.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=793578
Some source code comments amended to avoid possible future confusion.
It has been explained that a month name is used in a genitive case
only if it is required by the language rules. Also it has been
explained that %OB is also supported by other platforms (e.g., BSD)
but for this test we are focused on glibc 2.27 vs. Windows.
https://bugzilla.gnome.org/show_bug.cgi?id=749206
The CI infrastructure is shared and running inside a containerised
environment, which means tests may take more time to finish on it
than they would on a faster, personal machine.
https://bugzilla.gnome.org/show_bug.cgi?id=793635
The test for %OB with g_date_strftime() fails with old libc versions
which don’ŧ support the ‘O’ modifier. g_date_strftime() explicitly
doesn’t add additional format placeholders over what’s supported by the
system strftime(), so just disable the test in that case.
The test remains useful on systems with newer libc versions, or on
Windows, where the win32 fallback path is taken.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=749206
Add tests for g_date_strftime() and g_dat_set_parse() formatting and parsing
month names in both nominative and genitive case in several locales, both
needing these two grammatical cases and not needing them.
https://bugzilla.gnome.org/show_bug.cgi?id=749206
Supports %OB (alternative, standalone, nominative) month name along
with the old %B (primary, in a complete date format context, genitive)
month name. Similarly %Ob and %Oh for abbreviated month names.
Depending on the underlying operating system uses nl_langinfo()
or provides our custom implementation.
(Tweaked by Philip Withnall <withnall@endlessm.com> to add test case
comment and bug reference.)
https://bugzilla.gnome.org/show_bug.cgi?id=749206
The test_GDateTime_new_from_unix() test creates a UNIX timestamp
representing 1990-01-01 00:00:00 in the local timezone, and then turns
it into a GDateTime using g_date_time_new_from_unix_local(). This should
succeed regardless of the current local timezone (TZ environment
variable).
However, it was failing for TZ=America/Lima, and *only* for that
timezone.
As it turns out, Lima used to have a DST leap at exactly 00:00:00 on the
1st of January — but this stopped in 1994, which made investigation a
bit harder. See:
https://www.timeanddate.com/time/change/peru/lima?year=1990.
What was happening is that 1990-01-01 00:00:00 was being converted to
the timestamp 631170000, but GDateTime was converting that timestamp to
1990-01-01 01:00:00 when loading it. Both conversions are correct: a DST
leap creates an equivalence between an hour’s worth of timestamps.
We can somewhat validate this by seeing that timestamp 631169999 maps to
1989-12-31 23:59:59, and timestamp 631170001 maps to 1990-01-01
01:00:01.
Fix this by changing the date used by the test to one where no timezone
was undergoing a DST leap in 1990. This should never change, as all that
data is now historical.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=793319
g_key_file_get_locale_string() returns a translated string from the
keyfile. In some cases, it may be useful to know the locale that that
string came from.
Add a new API, g_key_file_get_locale_for_key(), that returns the locale
of the string.
Include tests.
(Modified by Philip Withnall to rename the API and fix some minor review
issues. Squash in a separate test case commit.)
https://bugzilla.gnome.org/show_bug.cgi?id=605700
This adds two new tests for g_bytes_new_from_bytes().
One test ensures that when creating a new GBytes that is a slice of
the entire base bytes, we just return the base bytes with it's reference
count incremented by one.
The other test ensures that when performing sub-slices of GBytes, for
which the parent GBytes also references a GBytes, that we skip the
intermediate GBytes and reference the base GBytes. Additional testing
of the internal state of the GBytes structure is performed to prove
the correctness of the implementation.
https://bugzilla.gnome.org/show_bug.cgi?id=792780
String inputs to convenience conversion functions g_locale_from_utf8(),
g_filename_from_utf8(), and g_filename_to_utf8(), are annotated for the
bindings as NUL-terminated strings of (type utf8) or (type filename).
There is also a len parameter that allows converting part of the string,
but it is exposed to the bindings as a value independent from the string
buffer. Absent any more sophisticated ways to annotate, the way to
provide a safeguard against len argument values longer than the
string length is to check that no nul is encountered within the first
len bytes of the string. strdup_len() includes this check as part of
UTF-8 validation, but g_convert() permits embedded nuls.
For g_filename_from_utf8(), also check the output to prevent embedded NUL
bytes. It's not safe to allow embedded NULs in a string that is going
to be used as (type filename), and no known bytestring encoding for
file names allows them.
https://bugzilla.gnome.org/show_bug.cgi?id=792516
If nl_langinfo() doesn’t support a particular item, it returns the empty
string. We should check for that and return NULL from
g_date_time_format() accordingly, otherwise the user could unwittingly
end up with a formatted date/time which is missing some or all of its
components.
This arose with %r in de_DE, which is unsupported by nl_langinfo()
because Germans almost never write time in 12-hour format.
Add a unit test.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=790416
Noticed these were missing when handling bug #733648. Add a few missing
tests to improve coverage.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
There are some GDateTime tests which need to be skipped if changing the
locale fails. Use g_test_skip() to do that, rather than just a
human-readable message.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
It's a very common pattern to see code that looks like this in
dispose() or finalize() implementations:
if (priv->source_id > 0)
{
g_source_remove (priv->source_id);
priv->source_id = 0;
}
This API allows to accomplish the same goal with a single line:
g_clear_handle_id (&priv->source_id, (GClearHandleFunc) g_source_remove);
Thanks to Emmanuele Bassi <ebassi@gnome.org> for making the patch
generic.
https://bugzilla.gnome.org/show_bug.cgi?id=788489
The carbon framework is deprecated and not really related to OSX's
printf features. Directly test compiler-defined token for the platform
itself rather than that autodetected framework as a proxy.
https://bugzilla.gnome.org/show_bug.cgi?id=731625
Ensures that the hostname returned by g_get_host_name is always UTF8 encoded.
Previously, on Windows, the returned string would be encoded in the
current codepage, if it contained non-ASCII characters.
The unit test for g_get_host_name was updated with a check to ensure
that the hostname is indeed at UTF-8 string.
https://bugzilla.gnome.org/show_bug.cgi?id=789755
