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
With the various macros we use to provide fallbacks for missing
nl_langinfo() fields, the locale handling can become quite complex:
nl_langinfo() returns strings encoded in the current locale, but C_()
returns strings encoded in UTF-8 (by GLib convention — you do actually
need to call bind_textdomain_codeset() to achieve this).
There are various format specifiers, especially with the new %Ob, %OB,
%Oh specifiers, which conditionally call nl_langinfo() or something
based on C_(). This makes encoding handling difficult.
Add additional macros which indicate whether the macros they’re paired
with return something encoded in the current locale, or encoded in
UTF-8. The user of the macro can then use these to work out whether to
re-encode.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=793578
If adding months or years to a date, the day of the month of the result
is supposed to be the same as in the input — but that doesn’t work if
that day doesn’t exist in the result month.
Clarify the documentation about what happens here (the day of the month
is clamped to the length of that month).
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Reviewed-by: nobody
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
A similar change to the commit be4f96b650,
supports %OB, %Ob, %Oh (alternative, standalone, nominative) month names
along with the old %B, %b, %h (primary, in full date format context,
genitive) month names.
https://bugzilla.gnome.org/show_bug.cgi?id=749206
On platforms other than Win32, the g_abort symbol is #def'd to abort.
C99 specifies that this function prototype resides in stdlib.h, but the
required include is absent from gutils.h.
https://bugzilla.gnome.org/show_bug.cgi?id=793555
One of the “quick” or “slow” test run modes is always added to the
argument list, making the branching pointless, which, coincidentally,
now causes a warning.
https://bugzilla.gnome.org/show_bug.cgi?id=793399
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 return value of the g_hash_table_add(), g_hash_table_insert(), and
g_hash_table_replace() functions was changed from void to gboolean in
GLib 2.40, but it was not mentioned in the API reference or the release
notes.
https://bugzilla.gnome.org/show_bug.cgi?id=793300
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
The existing array annotation is inconsistent with the other
conversion functions. Now that the implementation guarantees
no embedded NULs, the return value can be re-annotated.
https://bugzilla.gnome.org/show_bug.cgi?id=756128
Note that the g_convert() API works with byte arrays. It's wrong to
default to utf8 there, because iconv can read and produce strings with
interior nul characters which are not allowed in (type utf8).
The documentation was misleading about that in some places, so that got
corrected as well.
Strings in the locale encoding are annotated as dynamic-length byte
arrays because they don't have any guaranteed format and can contain
nul bytes. For UTF-8 strings in g_*_{from,to}_utf8(), GLib assumes
no embedded nul bytes and the (type utf8) annotations on the UTF-8
parameters and return values remain as they were. Likewise for
(type filename).
https://bugzilla.gnome.org/show_bug.cgi?id=756128
Introduced in commit 1574321e51.
This fix introduces no functional changes (just a cast).
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Reviewed-by: nobody
This seems to have been present since the code was introduced in commit
cedc82290f. The attr variable is defined
under one #ifdef, but destroyed under another, which doesn’t make any
sense. The second #ifdef variable is actually an enum value, rather than
the static initialiser value which makes more sense in the context.
Note that GMutex used to be statically initialised to the value of
PTHREAD_ADAPTIVE_MUTEX_INITIALIZER_NP in gthread.h, before this was
reworked in commit e081eadda5.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=793026
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
When compiling with G_LOG_USE_STRUCTURED, g_message(), g_debug(), etc.
use g_log_structured(). The message format string and its format
arguments are passed as the final set of arguments in a longer varargs
list, which includes the log domain and level (and other) fields.
Passing the message format in this way means it’s not possible for the
compiler to know to check its format placeholders when compiling with
-Wformat.
Fix support for this by adding a new semi-private helper function,
_g_log_structured_standard(), which only uses varargs for the message
format and its arguments, and uses fixed arguments for the other fields.
This is then converted to a set of GLogFields and passed to
g_log_structured() as normal.
Support for -Wformat when compiling *without* G_LOG_USE_STRUCTURED was
never broken.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=793074
The behaviour of upstream iconv() when faced with a character which is
valid in the input encoding, but not representable in the output
encoding, is implementation defined:
http://pubs.opengroup.org/onlinepubs/9699919799/
Specifically:
If iconv() encounters a character in the input buffer that is valid,
but for which an identical character does not exist in the target
codeset, iconv() shall perform an implementation-defined conversion
on this character.
This behaviour was being exposed in our g_iconv() wrapper and also in
g_convert_with_iconv() — but users of g_convert_with_iconv() (both the
GLib unit tests, and the implementation of g_convert_with_fallback())
were assuming that iconv() would return EILSEQ if faced with an
unrepresentable character.
On platforms like NetBSD, this is not the case: NetBSD’s iconv()
finishes the conversion successfully, and outputs a string containing
replacement characters. It signals those replacements in its return
value from iconv(), which is positive (specifically, non-zero) in such a
case.
Let’s codify the existing assumed behaviour of g_convert_with_iconv(),
documenting that it will return G_CONVERT_ERROR_INVALID_SEQUENCE if
faced with an unrepresentable character. As g_iconv() is a thin wrapper
around iconv(), leave the behaviour there implementation-defined (but
document it as such).
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=790698
Fix capitalisation of GLib, make some text less gender-specific, and add
some missing colons.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=790698
off64_t doesn’t exist in any standard (definitely not C99), and so
goffset is actually closer to off_t in 64-bit mode.
However, goffset is always defined as gint64, so make that clear.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=792856
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
When referencing a GBytes that is already a slice of another GBytes, we
can avoid referencing the intermediate GBytes and instead reference the
root bytes.
Doing so helps avoid keeping N GBytes instances alive when the
intermediates would have otherwise been finalized.
https://bugzilla.gnome.org/show_bug.cgi?id=792780
