`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
More vectors will give an error and we can simply clamp here and
consider it like a short write instead.
In case of GSocketOutputStream this is done here instead of inside
GSocket before calling sendmsg() because we we can't generically handle
short writes when sending messages on a socket, e.g. for datagram
sockets this causes only part of the datagram to be sent and an error
would be more useful in this case than sending corrupted data.
Also reduce the fallback limit to 16 in gsocket.c as that's the minimum
value required by POSIX and add a static assertion that the limit is
never bigger than G_MAXINT as that's the type recvmmsg/sendmmsg take.
lconv 1.13 only supports gcc <=7 and lcov 1.14 supports <=8.
msys2 was just updated to gcc9, so this wont help with coverage support, but
it's a start I guess.
Queries the charset used by the associated console, which does not
necessarily match the charset of the current locale as returned by
g_get_charset.
Fixes https://gitlab.gnome.org/GNOME/glib/issues/1270
As we discovered in GNOME/gtk#1280, GCC considers the pragmas to control
the deprecation warnings as statements. This means we cannot just use
the GLib wrappers as markers around the call site, but we must be aware
of their side effects.
Let's document this, to avoid falling into the trap.
file_copy_fallback creates new files with default permissions and
set the correct permissions after the operation is finished. This
might cause that the files can be accessible by more users during
the operation than expected. Use G_FILE_CREATE_PRIVATE for the new
files to limit access to those files.
The code in gunicollate uses __STDC_ISO_10646__ to check that wchar.h is avilable,
that it includes the wide character related functions and that sizeof(wchar_t) == 4.
cygwin defines __STDC_ISO_10646__ and has sizeof(wchar_t) == 2 and the C standard text isn't
that clear on whether wchar_t should always be 4 bytes in this case, so we better not use if for
assuming the size here.
Instead of relying on __STDC_ISO_10646__ add HAVE_WCHAR_H and SIZEOF_WCHAR_T macros.
With HAVE_WCHAR_H defined we assume wchar_t exists and wchar.h exists. With SIZEOF_WCHAR_T we
guard the parts where the size of wchar_t is assumed to be 4 (currently all of them).
Note that this doesn't make the collate tests pass under cygwin, they fail before and after this patch for me.
See !755 for related discussions.
When an application is launched using Launch Services
osx will add an extra parameter which we were not
handling and then gapplication would abort. Instead we make
an initial parsing and like this we avoid the abort if this
parameter is provided
Fixes https://gitlab.gnome.org/GNOME/glib/issues/1784
This is a new function along the same lines as g_test_bug(): to allow
developers to annotate unit tests with information about the test (what
it tests, how it tests it) for future developers to read and learn from.
It will also output this summary as a comment in the test’s TAP output,
which might clarify test results.
Includes a unit test.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Fixes: #1450
It allows to disconnect a signal handler from GObject instance and at the same
time to nullify the signal handler.
Provided also a macro for handler type conversion.
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 18745ff674 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.
