`NM_STATE_CONNECTED_SITE` is documented to mean that a default route is
available, but that the internet connectivity check failed. A default
route being available is compatible with the documentation for
GNetworkMonitor:network-available, which should be true if the system
has a default route for at least one of IPv4 and IPv6.
https://developer.gnome.org/NetworkManager/stable/nm-dbus-types.html
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Fixes: #1788
(cherry picked from commit e37f0cbd8914f16d509809a46977e6d32cf72a6e)
Factor out the code for setting up the hash table size, mask and mod,
detecting valgrind and allocating the arrays for hashes, keys, and
values.
Make use of this new function from g_hash_table_remove_all_nodes().
The handling of have_big_keys and have_big_values was never correct in
this function because it reallocated the array without changing the
flags in the struct. Any calls in to the hashtable from destroy
notifies would find the table in an inconsistent state.
Many thanks to Thomas Haller who is essentially responsible for all the
real work in this patch: both discovering and identifying the original
problem, as well as finding the solution to it.
Make it clear that there is a reference transfer going on here, rather
than relying on the fields being overwritten on each branch of the
conditional below.
We were calling g_hash_table_set_shift() to reinitialise the hash table
even in the case of destroying it. Only do that for the non-destruction
case, and fill the relevant fields with zeros for the destruction case.
This has a nice side effect of causing more certain crashes in case of
invalid reuse of the table after (or during) destruction.
The changes introduced by 18745ff674896c931379d097b18d74678044668e made
the comment at the top of g_hash_table_remove_all_nodes() no longer
correct. Fix that inaccuracy and add more documentation all-around.
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.
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
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 4d215e006ee69bd7a993bf853722993433adbf9a
and commit 7fe793e125c316ac34edd8158df5a132cb044bc1.
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
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 be4f96b6502c01d2a51d60b7a669c8ef82e22a4d.
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
The network-available property can be asserted by querying the NMState
describing the current overval network state, instead of the
NMConnectivityState. The advantage of the NMState is that is reflects
immediately the network state modification, while the connectivity
state is tested at a fixed frequency.
Other GCC-like implementations of ld/objcopy (like LLVM) don’t yet
support the right command line arguments, so can’t compile the test.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://gitlab.gnome.org/GNOME/glib/issues/1709
This introduces no functional changes, but combines two duplicated lists
and makes the meson.build file a little easier to follow.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Helps: #1711
macOS/iOS do not ship iconv inside the C library, so don't try to look
for that at all when targetting macOS or iOS.
The proper fix involved changing the options and will be merged in
master: https://gitlab.gnome.org/GNOME/glib/merge_requests/759
Closes: https://gitlab.gnome.org/GNOME/glib/issues/1566
Short names were used in win32 implementation to allow launching
on installations where full path to libgio-2.0-0.dll contain spaces.
However, short names are optional on windows: so if they were disabled
that method fails - see issue linked above.
Since rundll32 doesn't support neither spaces, nor quotes in cmdline
this patch changes rundll32 argument to just .\gio-dll-name.dll
and uses the entire path directory containing gio dll as rundll32
current directory.
Added comments informing about potential subtleties discovered during
writing test for gdbusaddress on win32.
There are not known to have real-world user-visible effect,
so by now I'm only adding comments without creating issues.
This is essentially a revert of commit
cc7f2f6b28573feb78c43fd16c555c4360b5a714. While those `flags` arguments
do accept values of type GSocketMsgFlags, they also accept OS-specific
flags which are not defined in GSocketMsgFlags.
The use of (type GSocketMsgFlags) makes language bindings like GJS
rightfully assert that values passed in to the argument only contain
flags from GSocketMsgFlags, which precludes the use of OS-specific
flags, and hence breaks various bits of code.
See https://gitlab.gnome.org/GNOME/gjs/issues/227#note_460136 and
https://gitlab.gnome.org/GNOME/glib/merge_requests/710#note_460249.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Fixes: https://gitlab.gnome.org/GNOME/gjs/issues/227
