g_hash_table_new_full() had an invocation of
g_hash_table_realloc_key_or_value_array() with the @is_big argument
incorrectly hardcoded to FALSE, even though later in the function the
values of have_big_keys and have_big_values would be set conditionally.
This never caused problems before because on 64bit platforms, this would
result in the allocation of a guint-sized array (which would be fine, as
have_big_keys and have_big_values would always start out as false) and
on 32bit platforms, this function ignored the value and always allocated
a gpointer-sized array.
Since merge request GNOME/glib!845 we have the possibility for
have_big_keys and have_big_values to start out as TRUE on 64bit
platforms. We need to make sure we pass the argument through correctly.
The caller cannot assume that the lists returned by various GSettings
functions (for example, lists of keys or schemas) will be returned in
any particular order.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Helps: #1781
For some reasons, the buffer used in the Format struct was not long
enough on Windows-x64 and the final null ('\0') character was omitted
leading to a limited memory disclosure.
Valgrind can't find 64bit pointers when we pack them into an array of
32bit values. Disable this optimisation if we detect that we are
running under valgrind.
Fixes#1749
Only disable TAP output if the `--GTestLogFD` argument is passed to the
test, which is passed in by the (deprecated) gtester harness, and
shouldn’t ever have been passed in by anything else.
Also disable it when running a subprocess, using `--GTestSubprocess`,
since users commonly strictly check the stdout and stderr of test
subprocesses.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Fixes: #1619
Add warnings about their deprecation everywhere. The tools will continue
to work until we break API, but will be less well maintained. You should
use TAP for communicating test results to the test harness provided by
your build system or CI system instead.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Fixes: #1441
Update the abbreviated month name in the test to match the actual
translation. Otherwise the test fails with false positive.
Vocabulary:
July (nominative) - Greek: Ιούλιος (abbreviated: Ιούλ)
Of July (genitive) - Greek: Ιουλίου (abbreviated: Ιουλ)
This is similar to commit 4d215e006e
and commit 7fe793e125.
Closes#1776
The parent GNetworkAddress contains a shared list of resolved
addresses that is used as a cache for multiple enumerations.
This commit ensures that the cache is only set upon completion of
DNS lookups and only read once by enumerations to avoid being in a
bad state.
Fixes#1771
This clarifies the meaning a bit. Don’t change the logic associated with
it. Add a few comments to clarify things further.
Based on work done by Emmanuel Fleury.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Fixes: #77
The correct spelling is "_NL_ABALTMON_n" rather than "_NL_ALTMON_n".
The typo made Meson build think that _NL_ABALTMON_n constants are
not supported which was totally wrong. This made g_date_time_format()
output incorrect abbreviated month names in some languages.
The old configure.ac script was correct here.
Bug introduced in commit be4f96b650.
Closes: #1759
We miss releasing the async operation's reference on a state object in
one of the error cases.
The call to connection_attempt_remove() (although it calls unref
internally) is not sufficient because this is releasing the reference
that the list owns.
Closes#1774
It gives clearer failure messages, and won’t get compiled out when
building with G_DISABLE_ASSERT.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
The current Debian stable CI image ships with Python 3.5, so the Meson
log to JUnit report script is failing because it's using an API addition
present in Python 3.6 or later.
Since it's just a cosmetic option for the time stamp, we can get rid of
it.
The documentation has marked it as deprecated for a long time, but not
in a structured way. Use the gtk-doc ‘Deprecated’ tag to mark it as
deprecated.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Helps: #1438
